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TITLE OF THE INVENTION 

A SYSTEM AND METHOD FOR A PASSIVE INTERNET CACHE 
BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The Passive Internet Cache system pertains to data caches in "star topology", dual 
channel (send and receive), and single channel (receive only, or "broadcast"), networks 1hat 

5 use the HyperText Transfer Protocol ("HTTP"). HTTP is very commonly used with 
Transmission Control Protocol/Internet Protocol ("TCP/IP") over the Internet or private 
networks that have a client/server architecture in which client software operated by an end 
user requests and receives information from one or more server computers. The structure 
of such requests and responses conforms with the specifications for HTTP. HTTP 

10 specifications are currently promulgated by the Worldwide Web Consortium, Cambridge, 
Massachusetts. 

An "HTTP request" from a World Wide Web browser, or other software 
application that uses HTTP messages, to a server computer contains a Uniform Resource 
Locator ("URL") to identify the requested information. The data contents at the address 
15 specified by a URL can be a complete Webpage, or components of a Webpage (text, 
graphics, sound, video, or other type of file). The "HTTP response" from the server to the 
browser contains the "contents" of the URL, but normally does not restate the URL. The 
cache that is included with commonly available Web browsers interoperates with the 
browser as follows: (a) an end-user clicks on a URL displayed in a browser or other 
20 window of the display of an electronic device, usually a computer, connected to the 
Internet; (b) the browser acts in conformity with the cache configuration settings of the 
browser, e.g., if the URL is stored in the built-in browser cache, the cache provides the 
contents of the stored URL to the browser unless required by the configuration settings to 
verify mat the cached URL has not changed; if verification is required, or if the URL isnot 
25 stored in browser cache, the cache sends an HTTP request message (usually including a 
"GET', or "GET IF-MODIFIED-SINCE" command) to request the URL from the host 
computer specified in the URL; (c) if the disk space used by browser cache exceeds auser- 
defined size, the cache deletes the oldest URLs in cache to accommodate the newest URLs 
and their contents; and (d) upon receipt of the HTTP response to the HTTP request, the 
30 cache provides the response to the browser and stores the contents of the HTTP response 
in browser cache under the URL specified in the matching HTTP request. The IP packet 
of an HTTP request includes, among other things, a GET (or other permitted) command, 
the requested URL, the IP address and TCP port number (collectively called the "source 
socket") of the end-user' s computer, and the destination IP address and TCP port number 
35 (collectively called the "destination socket") of the Webserver on which the URL resides. 
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The source socket of the HTTP request becomes the destination socket of the HTTP 
response, and the destination socket ofthe HTTP request becomes the source socketofthe 

HTTP response. 

An HTTP request causes the Webserver identified in the request message (i.e., the 
host computer at the domain name specified in the URL in the HTTP request) to send a 
Webpage (or Webpage component) identified by the file component ofthe URL to the 
requesting browser. The Webpage (or Webpage component) sent by the identified 
Webserver is the payload of the HTTP response message. "Browser" in this document 
means any end-user application software that uses HTTP . "HTTP" includes any equivalent 
or successor protocol to HTTP that performs "applications and services" functions at OSI 
layers 5 to 7 substantially similar to those of HTTP. "TCP/IP" includes any equivalent or 
successor protocol to TCP/IP that uses methods of message addressing, routing, transport, 
and headers that are substantially similar to those of TCP/IP. 

lnnormaloperation,aWebbrowser(orother software applicationthat uses HTTP) 
only receives the contents of TCP/IP packets that contain (a) the destination IP address of 
theelectromcdeviceonwWchmebrowserisrunning, and (b)aTCP port number assigned 
to the Web browser application for the duration ofthe TCP connection by the operating 
system ofthe electronic device (or by other software controlling the allocation of TCP 
ports on the device). "Electronic device" or "end-user node" means herein any type of 
computational device (a) under the control of an operating system, such as a personal 
computer ("PC"), set-top box, or Internet appliance, and (b) that is interfaced with a dual 
channel or single channel network. Anend-user node can be used by a human operator or 
be an unmanned processing node in a computer network. "End-user" means herem the 
client application (typically a browser) that originates HTTP requests and is the final 
recipientofHTTP responses. The most conunon network interfaces are network mterface 
cards and dial-up networking adapters. In normal operation, a Web browser opens a TCP 
port sends an HTTP request on that TCP port, and waits for an HTTP response on that 
TCP port More accurately, the browser (or other client application software) requests that 
meoperatmgsystemassigntomebwwser 
> unreservedTCPportnumber. The browser then uses that TCP port for a communications 
session. When the browser no longer needs the TCP port, the browser relinquishes the 
TCP port number(and therefore the TCP port the TCP port number identifies) back to the 
operating system, and the TCP port number can be reassigned to another application. 
Approximately sixty-four thousand TCP ports are available, which enables a browser to 
5 obtammmtiple,concurrentTCPportsandtoconductmmtiple,concurrentHTO 

Typically, the operating system assigns TCP port numbers in an ascending, sequential 
manner. WTien a TCP session is closed 
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system, the same port number will normally not be used again until the operating system 
has cycled through the remaining (approximately 64,000) TCP ports. If the IP destination 
address ofa packet available to a network interface of anelectronic device does notmatch 
the (or an) IP address of the network interface, the network interface normally ignores or 
discards the packet If the IP destination address does match the (or an) IP address of such 
network interface, the TCP/IP stack running in the electronic device forwards the contents 
of the packet to the application (e.g., browser) that opened the TCP port identified in the 
TCP packet header. If the specified TCP port is not open, the packet is ignored or 
discarded. 

A traditional standalone cache (not part of a Web browser) matches an HTTP 
request with the HTTP response generated as a reply to the HTTP request, and stores the 
contents of the HTTP response under the URL specified in the HTTP request The 
traditional standalone cache design requires collocation of the cache at a network access 
point where the cache can monitor and buffer traffic as required to provide the caching 
function. Being located at such a network access point permits a cache to monitor, copy 
and respond to HTTP requests and to store or cache HTTP responses that transit the access 
point. ThecachmgdevicecauseseachH^ 

in buffer memory and/or on a disk drive or other storage. When the URL is stored in the 
cache, the caching device accesses the buffered or cached information and responds to an 
HTTPrequestwiththecontentsoftherequestedURL. Ifa URL is not stored in the cache, 
or when it is necessary to verify that the requested URL has not changed (which depends 
on specific cache configuration settings), the cache opens a TCP/IP connection to the 
designated Webserver (on a separate TCP port managed by the TCP/IP stack serving the 
cache) and returns an appropriate HTTP response to the originator of the HTTP request 
after reviving the HTTP response from the Webserver. With traditional caching devices, 
the Webserver receives HTTP requests with IP headers containing the IP address and TCP 
port numbers assigned by the caching device rather than those of Ihe originating device, 

such as an end-user node. 

The term "star topology, dual channel network" as used herein means satellite and 
terrestrial network architectures in which a plurality of transmit/receive ('TR") remote 
terminals share a return channel (called the outbound channel) transmitted from a central 
switching, or "hub", node to the remote terminals, and in which each TR remote terminal 
uses a uniquely assigned forward communications channel (called the inbound channel) 
that is transmitted from a TR remote terminal to Ihe hub node and is not shared with (and 
; is not received by) other remote terminals. Very small aperture terminal C'VSAT") 
satellite networks with transmit/receive ("two-way") remote terminals are an example of 
a star topology, dual channel network In star topology, dual channel networks other than 
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two-way VS AT, the inbound channel from a TRremote terminal to a hub node serving the 
TR remote terminal can be through a terrestrial network, such as by use of terrestrial 
microwave, copper pair, or fiberoptic media; the outbound channel can also be through a 
terrestrial network, such as in digital cablecast networks. All TR remote terminals can 
5 communicate interactively with a hub node. 

The term "star topology, single channel network" as used herein means satellite and 
terrestrial network architectures in which a plurality of receive-only ("RO") remote 
terminals share a return channel (called the "broadcast" or outbound channel) from a hub 
node, and in which each RO remote terminal lacks any inbound channel, direct or indirect, 
10 from anRO remote terminal to a hub node. VSAT satellite networks with receive-only 
("one-way") remote terminals are a common example of a star topology, single channel 
network. A "star topology" network, without qualification as to channels, means star 
topology network with a population of TR remote terminals, RO remote terminals, or a 
mixed population of TR and RO remote terminals. A "remote terminal" means a device 
15 that uses radio frequency, electrical, photonic, or other communications technologies for 
one-way (RO) or two-way (TR) communications between that device and a hub node. A 
remote terminal can be interfaced with one or more local area networks, or equivalent 
connectivity, shared by end-user nodes and other types of nodes. 

A traditional, standalone cache interfaced with a TR remote terminal in a star 
20 topology, dual channel network can monitor (a) only the locally originated, remote 
terminal-to-hub node, inbound channel, and (b) a hub node-to-remote terminals, outbound 
channel. The locally originated inbound channel contains HTTP requests from end-users 
interfaced with the remote terniinal. The outbound channel contains HTTP responses to 
a plurality of remote terminals and the end-users interfaced with such remote terminals. 
25 A TR remote terminal in a star topology, dual channel VSAT network cannot directly 
monitor the inbound channels from other TR remote terminals to the hub node. An RO 
remote terminal in a star topology, single channel (broadcast) network does not have an 
inbound channel; there are no transmissions from the RO remote terminal to a hub node 
and therefore no inbound HTTP requests to monitor. An RO remote terminal also cannot 

30 direcuymomtorfoemboundchann^ A* 
RO remote terminal, however, may be interfaced with a local area network on which local 

HTTP requests are carried; a cache associated with an RO remote terminal can provide 

HTTP responses to local HTTP requests. Assuming a TR or RO remote terminal could 

receive HTTP responses addressed to other remote terminals, except in extremely rare 

35 instances described below, a traditional, standalone cache associated with such remote 

terminal can not determine the URLs of such HTTP responses. 
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2. Description of Related Art 

There are a great variety of caching technologies taught by prior art. Some caching 
methods are optimized for use in computer systems (U.S. Patent No. 5,930,5 15, issued to 
Ducharme, et al.), in Internet service provider operations (U.S. Patent No. 5,991,306, 
issued to Burns, et al.), or in satellite broadcasting (U.S. Patent No. 5,987,233, issued to 
Humphrey). The related art generally uses a "store and forward" approach in which files 
or data from a source device (e.g., a Webserver) are replicated on one or more other 
storage devices, or caches. The refresh frequency and selection of files and data is 
operator-defined or based on the actual or predicted frequency with which the files or data 
have been, or will be, requested by end users. Cache refresh can be either by the source 
initiating a refresh and "pushing" files and data out to cache storage, or by a destination 
initiating a refresh and "pulling" files and data from the source. Exi sting c aching 
methods can be configured using various rules for refreshing cache contents, for using 
drive space, for blocking specified URLs, etc. Such caches can also be configured for use 
as proxy servers, in which case an HTTP request generated by an end-user's browser uses 
a destination TCP port defined for the proxy server rather than using a well-known TCP 
port defined for public Webservers. TCP port 80 is a well-known port used by public 
Webservers for receiving HTTP requests. Caches can be cascaded, in which case each 
cache in series either contains the requested URL and returns the appropriate HTTP 
response to the requesting browser, or opens a TCP/IP connection to the next cache in 
series and sends an HTTP request to the next cache for the URL. In a cascaded cache 
architecture, when a cache does not contain a requestedURL, the cache generates an HTTP 
request to the next device in series, and upon receipt of the HTTP response (which may 
come from the next or subsequent cascaded caching device, or from the Webserver at the 
end of the cascade), forwards the HTTP response to the end-user, or to a previous cache 

in a cascaded series of caches. 

HTTP versions priorto HTTP 1.1 did not provide a field for the URL in the header 
of an HTTP response. The implication of this is that a device that monitors HTTP 
responses will not have access to the URL of the payload of an HTTP response when 
earlier versions of HTTP are used. This being the case, the URL and its contents cannot 
be cached when the HTTP request that generated the HTTP response is not available. 
When HTTP version 1 .1 or later is used, the Content Location header (a field reserved in 
an HTTP response for the URL of the payload of the response) is an optional field, and 
Webserver programmers are not required to include the field in the HTTP response. The 
use of the Content Location header is extremely rare; even when the Content Location 
header is included, the URL field may be missing or incorrect. When programmers do not 
include this field or the stated URL is missing or incorrect, an HTTP response cannot be 
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matched to the corresponding URL unless the HTTP request is available. 

None of the caching technologies described in the related art addresses the problem 
of a remote terminal in a star topology network not having direct access to the inbound 
channels of other remote terminals, or of the omission of URLs in HTTP responses in 
5 outbound channels. Traditional, standalone caching technologies for star topology, dual 
channel networks, such as that described in U.S. Patent No. 5,987,233, issued to 
Humphrey, require that a "global" standalone cache be maintained at one or more hub 
nodes (e.g.', the hub earth station of a VSAT network) and that a remote tenninal send 
HTTP requests through an inbound channel for all URLs that are not in the built-in 
10 browser cache, or other local cache, on a node interfaced with a remote terminal. The 
purpose of traditional caches, especially those associated with a hub node, is to reduce the 
volume of HTTP requests and HTTP responses transiting the span between the cache and 
the Internet, and therefore reduce the required datarate of (or increase the number of users 
supported over) such span. FIG.l depicts the current system of caching in a star topology, 
15 dual channel network. FIG 1A illustrates message exchange when a URL is in a local 
cache. FIG IB illustrates message exchange when a URL is not in local cache or in a 
traditional hub cache. In addition, the use of a traditional cache at ahub node of a satellite 
network provides a proxy function that "intercepts" end-users' HTTP requests for URLs, 
responds with those URLs cached at the hub node (which avoids Internet propagation 
20 delays), but does nothing to avoid the deterioration of response time due to satellite 
propagation delays between the end-user's node and the hub node. The contents of a 
"global" cache at a hub node reflect the activities of all end-users served by the hub 
node(s). In a multi-hub architecture, a "central" or "master" hub periodically collects the 
cache content from all other hub caches by pulling the contents from the hubs and creating 
25 an aggregate cache. The aggregate cache is then periodically pushed to the other hubs to 
replicate the aggregate cache at all hubs. In this architecture, the hub locations are 
generally terrestrial hubs, e.g. aninternet service provider point of presence, withend-users 
supported via terrestrial (usually dial-up) access to the hub node. Locating a global cache 
at a hub node has been necessary because only a hub node provides a network access point 
30 thatpermitsthemonitoringof aU HTTP requests from, and corresponding HTTP responses 
to, all remote terminals. Such caches generate, or obtain and relay, HTTP responses on 
behalf of client applications running on end-user nodes. Providing global caches at 
intermediate nodes or at end-user nodes ma star topology network has heretofore required 
that the cache contents be actively pushed or pulled from the "master caching center" or 
35 global cache at the hub node(s). An "intermediate node" is a node between the hub node 
and an end-user node in a star topology network. Accordingly, there is a need for a more 
efficient and cost effective method and system of building a global cache at intermediate 
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nodes and at end-user nodes in star topology networks. 

The Passive Internet Cache system overcomes the limitation of having to collocate 
a global cache with the hub node(s) of a star topology network, and the limitation imposed 
by the omission of the URL in HTTP responses. The Passive Internet Cache system uses 
an innovative, "passive listening" method to construct a global cache at any intermediate 
node, at a series of cascaded intermediate nodes, or at end-user node in star topology 
networks. The Passive Internet Cache system's provision of an HTTP response from a 
global cache at or very near an end-user node means higher cache "hit" rates for the end- 
user, faster response times, and a corresponding reduction in the use of inbound and 

outbound communication channels. 

SUMMARY OF THE INVENTION 

The Passive Internet Cache ("PIC") system meets the need for a more efficient and 
cost effective global cache in intermediate nodes or end-user nodes in star topology 
networks. The PIC system builds a global cache at or near end-user nodes, and 
substantially avoids response delays at end-user nodes arising from the exchange of request 
and response messages between a remote terminal and a hub node. Specifically, the PIC 
system operates in the background and enables end-user nodes interfaced with remote 
terminals to use the contents of all HTTP responses in an outbound channel, reduces the 
repetitive transmission of the same HTTP response payloads over an outbound channel, 
andindual channel networks also reduces the need to send HTTP requests over aninbound 
channel. The PIC system can be used and is effective in any type of star topology network. 
Suitable dual channel networks include VSAT systems with inbound and outbound 
channels by satellite, or with outbound channel by satellite and inbound channel by 
terrestrial network; Direct-to-Home ("DTO") satellite systems that have a broadcast 
outbound satellite channel and a terrestrial inbound channel (dial-up, leased line, cable 
modem, etc.); and terrestrial systems such as multichannel multipoint distribution service 
("MMDS"), local multipoint distribution service ("LMDS"), instructional television fixed 
service CnTS^d^gh^televisionbroadcastmg, and (Ugitd<5ablecastingsystemsuiathave 
a terrestrial "broadcast" or "multicast" outbound channel and various types of inbound 
channels. "Broadcast" means a single message in the outbound channel can be addressed 
to and received by all remote terminals. "Multicast" means a single message in the 
outbound channel can be addressed to and received by a portion of, but not all, remote 
terminals. In addition to star topology, dual channel networks, the PIC system is effective 
in networks with single channel, receive only terminals, such as receive-only VSAT and 
DTH satellite terminals. The PIC system is also effective with MMDS, LMDS, ITFS, 
digital television broadcasting, and digital cablecasting terminals that may have two-way 
(transmit/receive) or one-way (receive only) capabilities, whemer wireline and/or wireless. 
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A PIC system can be configured to serve a mixed population of TR remote terminals and 

RO remote terminals, and can be configured to use concurrently wireline outbound 

channels, wireless outbound channels, wireline inbound channels, and/or wireless inbound 

channels. This document assumes that end-users are associated with remote terminals and 

originate HTTP requests, and that Webservers (which may be on a local area network at 

the hub node, or may be accessed Ihrough other networks serving the hub node) provide 

HTTP responses to the hub node, and the hub node transmits such HTTP responses in the 

outbound channel to the remote terminals. 

The Passive Internet Cache system has five primary components: a monitoring 

component, an encapsulating component, a buffering component, an unencapsulating 
encapsulating'') component, and a global cache (called a "PIC Webcache"). Aprimary 
monitoring component and an encapsulation component are implemented at a hub node. 
Abuffering component can be implemented atahub node, intermediate node, and/or end- 
user node. The decapsulating component and the PIC Webcache are implemented at an 
intermediate node or at an end-user node of a star topology network. The decapsulating 
component is interfaced or integral with a buffering component at an intermediate node or 
at an end-user node. An example of an intermediate node is a computer or set-top box 
interfaced with, or integral with, a VSAT, DTH, MMDS, LMDS, ITFS, digital television 
broadcasting, or digital cablecasting remote tenninal and also interfaced with one or more 
end-user nodes; the interfaces can be a local area network, a system bus, universal serial 
bus ("USB"), or similar connectivity. The distribution of the components of aPIC system 
defines the various embodiments of the invention. All embodiments of the PIC system 
require that a remote terminal output all HTTP responses received in the outbound channel, 
not just those HTTP responses with IP addresses assigned to intermediate nodes and end- 
user nodes interfaced with such remote terminal, to each instance of a secondary 
monitoring component associated with or interfaced with such remote terminal. Such 
output can be obtained by setting configuration options with some commonly available 
remote terminal or hub node systems. If a remote terminal and hub node system does not 
support receptionofHTTP responses fornodesother than those attached to a given remote 
terminal, additional hardware and/or software components, such as a signal splitter and 
separate receiver/decoder, must be added to provide the ability to receive all HTTP 
responses in an outbound channel at a remote tenninal. 

One embodiment of the PIC system, inthe context of a star topology, dual channel 
VSAT network, implements a primary monitoring component and an encapsulating 
component at a hub earth station, and implements a secondary monitoring component, a 
decapsulating component, a buffering component, and a PIC Webcache on an end-user 
node interfaced with a VSAT remote terminal. On the end-user node, the PIC Webcache 
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is configured asaproxy server cache andthe Web browser is configured to use such proxy 
server cache. The primary monitoring component of the PIC system at the hub earth 
stationmonitors all inbound channels fromall the VSAT remote terminals to the hub earth 
station. The primary monitoring component copies all HTTP requests from the monitored 
inbound channels, forwards the HTTP requests to the encapsulating component at the hub 
earth station where the HTTP requests are immediately encapsulated in a User Datagram 
Protocol ("UDP") message. Such UDP messages are then immediately transmitted in the 
outbound channel using a broadcast IP address and UDP port monitored by all remote 
terminals matrece^ 
) has a PIC Webcache. The secondary monitoring component at the end-user node 
communicates through a network interface on the end-user node with the VSAT remote 
terminal. The secondary monitoring component at the end-user node also communicates 
with the decapsulation component and withthebufferingcomponentontheend-usernode. 
The secondary monitoring component copies from the VSAT remote terminal to the 
5 decapsulation component all UDP messages, and to the buffering component all HTTP 
messages, received by the remote terminal, not just those packets with an IP destination 
addressoftheend-usernode. When Ihe secondary monitoring component on Ihe end-user 
node receives a UDP packet containing an encapsulated HTTP request, it provides such 
packet to me decapsulation component. The decapsulation component removes the UDP 

>0 encapsulation ("decapsulation"), and forwards the decapsulated HTTP request to the 
buffermgcomponentonmeend-usernode.Thebuffermgcomponentonmeend^ 

communicates with disk drive(s) or other read/write storage devices) associated with the 
end user node that are used by the PIC Webcache for storage. The buffering component 
at the end-user node stores the decapsulated HTTP request in buffer memory, and opens 
25 a file (or database record) tagged with the source socket (source IP address and TCP port 
number) and the destination socket (destination IP address and TCP port number) specified 
in the decapsulated HTTP request. The tagged file (or database record) awaits the arrival 
of the relevant HTTP response to be delivered later by the buffering component 

Upon receipt at the hub earth station of an HTTP response from a Webserver, the 
30 hub earth station transmits the HTTP response in the outbound channel. If a browser 
runiungonaend-usernodemterfacedwimaVSATremoteterminalorigm^^ 
request that generated the HTTP response, the HTTP response is received in the outbound 
channel by that VSAT remote terminal, forwarded to the PIC Webcache in the normal 
manner, and delivered by the PIC Webcache, operating as a proxy server cache, to the 
35 requesting browser. The secondary monitoring component at the end-user node also 
forwards every HTTP response in the outbound channel to the buffering component 
running on the end-user node. If a browser running on an end-user node interfeced with 
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a VSAT remote terminal did not originate the HTTP request that generated the HTTP 
response, the contents of the HTTP response are not passed to the browser upon receipt 
Rather thebuffering component exanunes me HTTP response to determine the source and 
destination sockets and stores the contents of the HTTP response in the file (or database 
record) previously tagged with those sockets (but with source and destination sockets 
reversed in the HTTP request as compared with the HTTP response). After receiving both 
the HTTP request and the HTTP response, the buffering component at the end-user node 
can match the HTTP request with the correct HTTP response, extract the URL identity 
from the HTTP request, and create a file (or database record) for the URL on the storage 
device(s)usedbythePICWebcache as if the browser itself had caused the PICWebcache 
to cache the URL and its contents, but without displaying the URL contents and without 
issuing an HTTP request. To receive and store the HTTP response, the PIC system does 
not obtain or use a TCP port number allocated by the end-user node or interfere with 
normal browser operation. If the browser requests a PIC-cached URL in the future, the 
contents of the URL will already be in the PIC Webcache, and will be delivered instantly 
from the PIC Webcache to the browser. 

In summary, the Passive Internet Cache system without buffering at a hub node 
comprises a hub node of a star topology network that receives HTTP requests from one 
or more remote terminals, which hub node is interfaced with at least one external server 
computer and transmits UDP datagrams, HTTP requests, and HTTP responses in an 
outbound channel from said hub node of the star topology network, and one or more 
intermediate or end-user nodes of said network that receive said UDP datagrams, HTTP 
requests, and HTTP responses and which one or more intermediate or end-user nodes 
are associated with or interfaced with a means for socket-matching HTTP requests and 
HTTP responses and for storing in an end-user accessible cache the contents of a given 
HTTP response under the URL extracted from a correctly matched HTTP request. 

The Passive Internet Cache system with buffering at a hub node comprises a hub 
node of a star topology network that receives HTTP requests from one or more remote 
terminals, which hub node is interfaced with at least one external server computer, has a 
first means for socket-matching, and transmits UDP datagrams, HTTP requests, and 
HTTP responses in an outbound channel from said hub node of the star topology 
network, and one or more intermediate or end-user nodes of said network that receive 
said UDP datagrams, HTTP requests, and HTTP responses and which one or more 
intermediate or end-user nodes are associated with or interfaced with a second means 
i for socket-matching HTTP requests and HTTP responses and for storing in an end-user 
accessible cache the contents of a given HTTP response under the URL extracted from 
a correctly matched HTTP request 



10 



WO 01/88761 PCT/US01/15575 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other aspects and features of the Passive Internet Cache system 
will be better understood from the Mowing more detailed description and appended 
claims in conjunction with the drawings, of which: 

FIG. 1 illustrates the current system of caching in a star topology, dual channel 

network. 

FIG 1 A illustrates message exchange when a URL is in a local cache. 

FIG IB illustrates message exchange when a URL is not in local or hub cache. 

FIG. 2 UlustatesmePassivefotemet tache em 
PIC Webcache at an end-user node in a star topology, dual channel network (first 
embodiment). 

FIG. 2A illustrates the distribution of PIC components in the first embodiment. 
FIG. 2B illustrates passive hastening and encapsulation at a hub node. 
FIG. 2C illustrates socket matching. 

FIG. 2D illustrates message exchange using socket matching to store URLs and 
URL contents in a PIC Webcache in the first embodiment. 

FIG. 3 illustrates the Passive Internet Cache embodiment with socket matching at 
an intermediate node and with PIC Webcache at an end-user node in a star topology, dual 
channel network (second embodiment). 

FIG. 3 A illustrates the distribution of PIC components in the second embodiment. 

FIG.4illustratesthe Passive InternetCache embodimentwimsocketmatchingand 
PIC Webcache at an intermediate node in a star topology, dual channel network (third 
embodiment). 

FIG. 4A illustrates the distribution of PIC components in the third embodiment. 

FIG. 5 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node and with secondary buffering andPIC Webcache at an end-user node in astar 
topology, dual channel network (fourth embodiment). 

FIG. 5 A illustrates the distribution of PIC components in the fourth embodiment. 

FIG. 6 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node, with secondary buffering at an intermediate node, and with PIC Webcache 
at an end-user node in a star topology, dual channel network (fifth embodiment). 

PIG. 6A illustrates the distribution of PIC components in the fifth embodiment. 

FIG. 7 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node and with PIC Webcache at an intermediate node in a star topology, dual 
channel network (sixth embodiment). 

FIG. 7A illustrates the distribution of PIC components in the sixth embodiment. 

FIG. 8 illustrates the Passive Internet Cache embodiment with socket matching and 
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PIC Webcache at an end-user node in a star topology, single channel network (seventh 
embodiment). 

FIG. 8A illustrates the distribution of PIC components in the seventh embodiment. 

FIG. 9 illustrates the Passive Internet Cache embodiment with socket matching at 
anmtemediate node and wimPICW^ 
channel network (eighth embodiment). 

FIG. 9A illustrates the distribution of PIC components in the eighth embodiment. 

FIG. 10 illustrates the Passive Internet Cache embodiment whh socket matching 
and PIC Webcache at an intermediate node in a star topology, single channel network 

(ninth embodiment). 

FIG. 10A illustrates the distribution of PIC components in the ninth embodiment. 

FIG. 1 1 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node and with secondary buffering and PIC Webcache at an end-user node in 
a star topology, single channel network (tenth embodiment). 

FIG. 11A illustrates the distribution of PIC components in the tenth embodiment. 

FIG. 12 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node, with secondary buffering at an intermediate node, and with PIC 
Webcache at an end-user node in a star topology, single channel network (eleventh 

embodiment). < 

FIG. 12A illustrates the distribution of PIC components m the eleventh 

embodiment. 

FIG 13 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node and with secondary buffering and PIC Webcache and at an intermediate 
node in a star topology, single channel network (twelfth embodiment). 

FIG. 13 A illustrates the distribution ofPIC components in the twelfth embodiment 

FIG. 14 is a block diagram of intermediate node and end-user node functional 
modules in a star topology, dual channel network 

FIG. 14A is a block diagram of hub node functional modules node in a star 

topology, dual channel network. 

FIG. 1 5 is a block diagram of intermediate node and end-user node functional 

modules in a star topology, single channel network. 

FIG. 15A is a block diagram of hub node functional modules node in a star 

topology, single channel network 

FIG. 16 is ablock diagram of a PIC system with content authorization. 

FIG. 17 isablock diagram of error correction byabuffering component based on 
continuity of TCP sequence numbers. 
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DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Preferred embodiments of the invention will now be described with reference to 
FIGS 1 to 17. It will be appreciated by those of ordinary skill in the art that the 
description given herein with respect to those figures is for exemplary purposes only and 
5 is not intended in any way to limit the scope of the invention. 

The Passive Internet Cache has five components, some of which may be distributed 
among hub, intermediate, and/or end-user nodes, as described below. The five 
component are: a monitoring component, an encapsulating component, a buffering 
component, an ^encapsulating ("decapsulating") component, and a global cache 
10 (called a "PIC Webcache"). A primary monitoring component and an encapsulation 
component are implemented at hub node(s) in all embodiments. A buffering 
component can be implemented at a hub node, intermediate node, and/or end-user node. 
The primary monitoring component at a hub node monitors all IP addresses and TCP 
ports involved in HTTP sessions in use by all nodes using inbound and outbound 
15 channels handled by such hub node, and provides those addresses and ports to the 

various implemented buffering component© to enable tracking of all IP addresses and 
TCP ports involved in HTTP sessions; such buffering and tracking enables the 
matching of source sockets and destination sockets used in each of the embodiments. 
The encapsulating component encapsulates HTTP requests in broadcast UDP (or other 
20 connectionless protocol suitable for broadcast or multicast transmission) messages that 
are transmitted from a hub node through an outbound channel and are addressed to all 
remote terminals that can receive that outbound channel. A secondary monitoring 
component, a decapsulating component, a buffering component, and a PIC Webcache 
can be implemented at an intermediate node or at an end-user node. The decapsulating 
25 component is interfaced or integral with a buffering component at an intermediate node 
or at an end-user node. An example of an intermediate node is a computer or set-top 
box interfaced with, or integral with, a remote terminal and also interfaced with one or 
more end-user nodes; the interfaces can be a local area network, a system bus, USB, or 
similar connectivity. "Associated with" means two hardware or software devices are 
30 either integral or very closely interfaced, as through a system bus, proximate area 
network, USB, high speed local area network, or other close range connectivity, for 
message exchange. "Interfaced with" means two hardware or software devices are 
closer in distance to each other than to the hub node, normally have a higher datarate 
connection between such devices than to the hub node, and are interconnected through 
35 a local area network, or other medium range connectivity, for message exchange. 

"Buffer" or "buffer memory" means random access memory, disk storage, or equivalent 
read/write technology suitable for the short term storage and retrieval of digital 
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information. 

With reference to FIG. 2B, passive listening and encapsulation is implemented at a 
hub node of a dual channel, star topology network by providing a primary monitoring 
component (201) with unlimited, or "promiscuous," access to all HTTP messages 
inbound from remote terminals. A hub node in such a star topology network typically 
has a plurality of remote terminals whose inbound channels (each denoted "Rev" in 
FIG. 2B) are received at the hub node, and whose TCP/IP messages are routed to the 
Internet, a private network, and/or a traditional cache. The primary monitoring 
component (201) listens to all inbound HTTP messages in such TCP/IP messages, and 
provides HTTP requests to the encapsulation component (202). The encapsulation 
component (202) encapsulates each HTTP request as a broadcast UDP (or other 
connectionless protocol suitable for broadcast or multicast transmission) message and 
provides each such message to the outbound channel of the hub node (denoted as 
"Xmit"inFIG.2B). 

The distribution of the components of aPIC system within a star topology network 
defines the various embodiments of the invention. All embodiments of the PIC system 
require that a remote terminal output all HTTP responses received through the outbound 
channel, not just those HTTP responses with IP addresses assigned to intermediate nodes 
and end-user nodes interfaced with such remote terminal, to each instance of a secondary 
monitoring component associated with or interfaced with such remote terminal. Such 
output can be obtained by setting configuration options with some commonly available 
remote terminal or hub node systems. In other instances, existing remote terminal and hub 
node systems may not support reception of HTTP responses by a remote terminal other 
than HTTP responses addressed to a specific remote terminal; in these cases, additional 
hardware and/or software components must be added to a remote terminal to provide the . 
ability to receive all HTTP responses in an outbound channel. Where such additional 
hardware and software components are required to receive all HTTP responses in an 
outbound channel, a signal splitter (e.g., a RF- or IF-band splitter for wireless outbound 
channels) and separate receiver/decoder installed at a remote terminal is usually sufficient. 

The HTTP requests and HTTP responses transmitted through the communications 
paths in a PIC system are not handled through a traditional TCP/IP stack and do not 
involvetheuseofTCP acknowledgements. The buffering component, whether associated 
with or interfaced with a hub node, an intermediate node, or an end-user node, uses socket- 
matching to pair an HTTP request with the correct HTTP response. With reference to 
FIGS. 2 and 2C, in the socket-matching process in a PIC embodiment with buffering and 
PIC Webcache at an end-user node, the buffering component (206) examines the packets 
forwarded by the secondary monitoring component (204). The field sequence observed 
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in HTTP packets is: source IP address (abbreviated "IPs-" in FIG. 2C), destination IP 
address (abbreviated 'TP d-" in FIG. 2C), source TCP port number (abbreviated "TCPs-" 
in FIG. 2C), destination TCP port number (abbreviated "TCPd-" in FIG. 2C), and the 
payload (either an HTTP request or an HTTP response). The secondary monitoring 
component (204) forwards each HTTP response (the first packet in packet stream 220, in 
FIG 2C) directly to the buffering component (206) and forwards each UDP packet (the 
second packet in packet stream 220, in FIG 2C) to the decapsulation component (205, in 
FIG. 2), which decapsulates any HTTP request contained in suchpacket and forwards the 
HTTP request so decapsulated to the buffering component (206). When the buffering 
component (206) receives an HTTP response, it examines the source and destination 
sockets, and checks to see if a file (or database record) in buffer memory containing an 
HTTP request has been tagged withthose source and destination sockets. The source and 
destination sockets are reversed in an HTTP request as compared with the corresponding 
HTTP response. The buffering component compensates for the reversal of source and 
destinationsocketswhenitcomparesHTTPrequestsandHTTP responses. If the buffering 
component can match a received HTTP response wim a buffered HTTP request, it extracts 
the URL identity from the HTTP request, and creates a file (or database record) for the 
URL onlhe storage device(s) (212, inFIG. 2) used by the PIC Webcache (207, inFIG. 2) 
as if the PIC Webcache itself had cached the URL. If the buffering component cannot 
match the a received HTTP response with a buffered HTTP request, the buffering 
component creates a file (or database record) tagged with the sockets of the HTTP 
response, and stores suchfile(or database record) in buffermemory. In the caseofpacket 
stream (220), the HTTP response with addressing of "IPsb, IPda, TCPsb, TCPda," in the 
first portion of packet stream (220) would be buffered and subsequently matched with the 
decapsulatedHTTP request wim addressing of«IPsa,IPdb,TCPsa,TCPdb,''inthe second 
portion of packet stream (220). To introduce a second example of socket matching, if the 
buffering component (206) receives the HTIT request m me first packet in packet stream 
(221) that contains source and destination sockets that the buffering component cannot 
match with a previously buffered HTTP response, the buffering component creates a file 
(or database record) tagged with the sockets of that HTTP request, and buffers such file (or 
database record). When the buffering component subsequently receives the HTTP 
response in the second portion of packet stream (221), it examines the source and 
destination sockets of that HTTP response, matches those sockets with the previously 
buffered file (or database record) tagged with those source and destination sockets 
(compensatmgformereversalofsourceanddestination sockets), extracts the URL identity 
from the HTTP request, and creates a file (or database record) for the URL on the storage 
device(s)(212) used by the PIC Webcache (207) as ifthe PIC Webcache itself had cached 
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the URL. Regardless of whether the HTTP request or the HTTP response is received first, 
to receive and store the URL and the contents of the URL, the PIC system does not obtain 
or use aTCP port number allocated by the end-user node. Thus, even though the browser 
at the end-user node had not previously requested a URL in the PIC Webcache, if the 
browser does request that URL in the future, the contents of the URL will already be in the 
PICWebcache serving thebrowser,andwillbe delivered instantlyfrom the PIC Webcache 
to the browser. 

FIG. 2D illustrates the messages exchanged in the operation of a PIC Webcache in 
a PIC embodiment with buffering and PIC Webcache at an end-user node. In FIG. 2D, an 
unseen remote terminal transmits an HTTP request that is monitored by the primary 
monitoring component at a hub node and handled as described above and as depicted in 
the upper, leftward message flows in FIG. 2D. That HTTP request is also sent in the 
customary manner from the hub node to a traditional proxy or cache as depicted in the 
upper, rightward message flows in FIG. 2D; if the URL is not found in the traditional 
15 proxy or cache, the HTTP request is forwarded to the Webserver identified in the URL. 
The traditional proxy or cache, or the Webserver, as the case may be, replies to the HTTP 
request with an HTTP response, which the hub node transmits in the outbound channel as 
described above and as depicted in the lower, leftward message flows in FIG. 2D. 
Socket-matching and storage of the URL and its contents is performed at the end-user 
20 node, as described above. 

The buffering component in the first embodiment only proceeds with writing the 
contents of the HTTP response in the PIC Webcache under the URL contained in the 
HTTP request if no errors are detected in the HTTP response and HTTP request. The 
buffering component uses the error detection techniques of TCP, such as confirming a 
25 continuous series of TCP header sequence numbers, to detect errors. If no errors are 
detected, the buffering component writes the contents of the matched HTTP response in 
the PIC Webcache under the URL contained in the matching HTTP request. If errors are 
detected in an HTTP request, the request is discarded, and any HTTP responses that have 
not been matched after the expiration of an operator-controlled time period are also 
30 discarded. If errors are detected in an HTTP response, and the intermediate node or end- 
user node has access to an inbound channel, the buffering component can issue an HTTP 
request for a replacement HTTP response. If errors are detected in the HTTP response, and 
the intermediate node or end-user node does not have access to an inbound channel by 
which to issue an HTTP request, the matched but defective HTTP response and matching 
35 HTTP request are discarded. Normally, any single end-user node would only request a 
small portion of me contents of a PIC Webcache within a given time period, so such 
discarding of corrupted or missing HTTP responses and HTTP requests should have an 
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insignificant impact on the overall performance improvements afforded by use of a PIC 
Webcache. 

The embodiments of the PIC system fall into two categories: embodiments for dual 
channel, star topology networks, and embodiments for single channel, star topology 

5 networks. With each category, there are two sub-categories of embodiments: 
embodiments that perform initial socket-matching at a hub node, and embodiments that 
that do not perform any socket-matching at a hub node. FIGS. 14 and 14A are block 
diagrams of intermediate node, end-user node, and hub node functional modules in a star 
topology, dual channel network. FIGS. 15 and 15A are block diagrams of intermediate 

10 node, end-user node, and hub node functional modules in a star topology, single channel 
network. Within each sub-category, there are three basic embodiments that are 
distinguished by whether a buffering component is implemented at an intermediate node 
or at an end-user node, and by whether a PIC Webcache is implemented at an intermediate 
node or at an end-user node, as illustrated in FIGS. 14 and 15 for dual channel and single 

15 channel networks, respectively. 

First Embodiment : Buffering and PIC Webcache at end-user node (TR: Socket Matching 

at End-User Node ("EUN")) 

FIG. 2 illustrates the Passive Internet Cache embodiment with socket matching and 
PIC Webcache at an end-user node in a star topology, dual channel network. FIG. 2A 

20 illustrates the distribution of PIC components in the first embodiment. FIG. 2B illustrates 
passive listening and encapsulation. FIG. 2C illustrates socket matching. FIG. 2D 
illustrates message exchange using socket matching to store URLs and URL contents in 
a PIC Webcache in the first embodiment. Reference numerals for the first embodiment are 
to Fig. 2 unless otherwise noted. 

25 A first embodiment of the Passive Internet Cache system in a star topology, dual 

channel network implements a primary monitoring component (20 1) and an encapsulation 
component (202) at a hub node (203 in Fig. 2 A), and a secondary monitoring component 
(204), a decapsulation component (205), a buffering component (206), and a PIC 
Webcache (207) at an end-user node (208 in Fig. 2A) interfaced with a remote terminal 

30 (209). In the context of a star topology, dual channel network, this embodiment of the 
Passive Internet Cache system provides the lowest cost end-user node for a PIC system. 
Assuming a remote terminal can output all HTTP responses by the use of configuration 
settings, the typical PIC components at the end-user node are software modules installed 
on an end-user PC and, as such, require no hardware investment to implement The PIC 

3 5 Webcache is configured as a proxy server cache and the Web browser on the end-user node 
is configured to use such proxy server cache. The primary monitoring component (201) 
at the hub node (203) monitors all inbound channels transmitted from all the remote 
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terminals (209, 213) to the hub node (203). The primary monitoring component (201) 
copies all HTTP requests from the monitored inbound channels (214, 215), provides each 
HTTP request to the encapsulating component (202), and the encapsulating component 
(202) immediately encapsulates each copied HTTP request in a UDP (or other 
connectionless protocol suitable for broadcast or multicast transmission) message. The 
encapsulating component provides each UDP message to the outbound channel (21 6) for 
transmissioninthe outbound channelusing abroadcastIP address andUDP port (or other 
suitable protocol, address, and port) monitored by all remote terminals that receive such 
outbound channel and are interfaced with PIC components on end-user nodes. The 
secondary momtormg component (204) onme end-user node (208) commumcates^ 
a network interface on the end-user node with the remote terminal (209). Using a first 
communications path (210) on the end-user node (208), the secondary monitoring 
component (204) also communicates with the decapsulation component (205), and the 
decapsulation component (205) communicates with the buffering component (206). The 
secondary monitoring component (204) copies all of the encapsulated UDP packets from 
the remote terminal (209) to the decapsulation component (205) through a first portion of 
the first communications path (210). When the secondary monitoring component (204) 
on the end-user node provides a UDP packet containing an encapsulated HTTP request to 
medec^smauoncomponent(205),M 

encapsulation ("decapsulation"), and forwards each decapsulated HTTP request to the 
bufferingcomponent (206) atthe end-user node (208 in FIG. 2A) through a second portion 
of the first communications path (210). The buffering component (206) at the end-user 
node communicates with disk drive(s) (212) or other read/write storage device(s) 
associated with the end user node that are used by the PIC Webcache (207) for storage. 
The buffering component (206) stores the decapsulated HTTP request in buffer memory, 
andopens afile (or database record) tagged withthe source socket (source IP address and 
TCPportnumber) andmedestinationsoc^^ 

specified in the decapsulated HTTP request. The tagged file (or database record) would 
normally be on the storage device(s) used by the PIC Webcache. The tagged file (or 
database record) awaits the arrival of the contents of the relevant HTTP response to be 
delivered later from the buffering component 

Upon receipt at the hub node of an HTTP response, the hub node (203 inFIG. 
2A) transmits the HTTP response in the outbound broadcast channel (216 in FIG. 2). If 
a browser running on a end-user node interfaced with a remote terminal originated the 
, HTTP request that generated the HTTP response, the HTTP response is received in the 
outbound channel by that remote terminal, forwarded to the PIC Webcache in the 
nonnal manner, and delivered by the PIC Webcache, operating as a proxy server cache, 
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to the requesting browser. The secondary monitoring component (204) forwards 
through a second communications path (21 1) to the buffering component on the end- 
user node all HTTP packets received by the remote terminal (209), not just those 
packets with an IP destination address of the end-user node (208). If a browser running 
on an end-user node interfaced with a remote terminal did not originate the HTTP 
request that generated the HTTP response, the contents of the HTTP response are not 
passed to the browser upon receipt Rather, the buffering component on the end-user 
node examines the HTTP response to determine the source and destination sockets and 
stores the contents of the HTTP response in the file (or database record) previously 
tagged with those sockets (the source and destination sockets are reversed in the HTTP 
request as compared with the HTTP response). After receiving both the HTTP request 
and the HTTP response, the buffering component at the end-user node can match the 
HTTP request with the correct HTTP response, extract the URL identity from the 
HTTP request, and create a file (or database record) for the URL on the storage 
device(s) (212) used by the PIC Webcache as if the PIC Webcache itself had cached the 
URL. To receive and store the HTTP response, the PIC system does not obtain or use a 
TCP port number allocated by the end-user node. If the browser requests that URL in 
the future, the contents of the URL will already be in the PIC Webcache serving the 
browser, and will be delivered instantly from the PIC Webcache to the browser. 

In the event the browser running on an end-user node interfaced with a remote 
terminal did not originate the HTTP requestthat generated an HTTP response provided by 
the monitoring component at the end-user node to the buffering component at the end-user 
node, and the buffering component at the end-user node has not yet received, via a UDP 
message from the hub node, a copy of the HTTP request that triggered such HTTP 
response, the buffering component at the end-user node stores the HTTP response in buffer 
memory,taggedby source socket and destimtion socket, until me associated HTTP request 
arrives via a UDP message from the hub node. Upon receipt and decapsulation of the 
HTTP request, the buffering component can match the HTTP request with the correct 
HTTP response, extract the URL identity from the HTTP request, and create a file (or 
database record) for the URL on the storage device(s) used by the PIC Webcache as if the 
PIC Webcache itself had cached the URL and its contents. 

R^nnd Embodiment : Buffering at intermediate node andPIC Webcache at end-user node 
(TR: Socket Matching at intermediate node ("IN")) 

FIG. 3 illustrates the Passive Internet Cache embodiment with socket matching at 
an intermediate node and with PIC Webcache at an end-user node in a star topology, dual 
channel network. FIG. 3 A illustrates the distribution of PIC components in the second 
embodiment Reference numerals are to FIG. 3 unless otherwise noted. 
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A second embodiment of me Passive Internet Cache system in a star topology, dual 
channel network implements abuffering component (306) at an intermediate node (3 17 in 
FIGS. 3 and 3A) and a PIC Webcache (307) at an end-user node (308 in FIGS. 3 and 3A. 
The second embodiment has the advantage of requiring only one instance of a buffering 
component interfaced with a given remote terminal; the buffering component serves all 
end-user nodes on one or more local area networks (or other local connectivity) served by 
thatremoteterminal. This embodiment provides fast end-user response times through the 
use of PIC Webcaches at end-user nodes. Additionally, the use of a separate processor for 
me monitoring and buffering components at an intermediate node permits higher 
performance memory and a dedicated processor or processors to handle these functions, 
off-loading those processing requirements from the end-user nodes. TCP/IP is used in the 
local area network (or other connectivity) between the buffering component at me 
intermediate node and the PIC Webcache in end-user nodes. 

The second embodiment of the Passive Internet Cache system implements a 
primary monitoring component (301) and an encapsulationcomponent(302)atahub node, 
a secondary monitoring component (304) , a decapsulation component (305), and a 
buffering component (306) at a computer or set-top box that is interfaced with, or is an 
integral part of, a remote terminal (309) and is also interfaced with a local area network 
(318) (or other connectivity) that serves one or more end-user nodes, and the PIC 
Webcache (307) component at one or more end-user nodes (308). The end-user nodes may 
also conmumcate dfrectiy wito a remo 

system. The PIC Webcache in this embodiment is configured as a proxy server cache and 
me Web browser on me end-user node is configured to use such proxy server cache. The 
primary monitoring component (301) and the encapsulation component (302) of the PIC 
system at the hub node (303) function as described above. The secondary monitoring 
component (304) at the intermediate node communicates through a network, internal bus 
or other interface with the remote terminal. The secondary monitoring component (304) 
also communicates with the decapsulation component (305), and with the buffering 
component (306), at the intermediate node. The secondary monitoring component (304) 
copies from the remote terminal (309) to the decapsulation component (305) on the 
intermediate node all encapsulated UDP packets, and to the buffering component (3 06) on 
the intermediate node, all HTTP packets, received by the remote terminal, not just those 
packets wim an IP destination address of the intermediate node orof end-user nodes served 
by that remote terminal. When the secondary monitoring component (304) receives a 
UDP packet containing an encapsulated HTTP request, it provides such packet through a 
first portion of a first communications pam (310) to the decapsulation component (305) at 
Hie intermediate node. The decapsulation component (305) decapsulates the HTTP 
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request, andforv^seachdecapsulatedHTTPrequestthroughasecondp 
communications path (310) to the buffering component (306) at the intermediate node. 
The buffering component (306) at the intermediate node communicates with disk drive(s) 
orother read/write storage device(s)(312)associatedwitheachendusernodethatareused 
by one or more end-user nodes' PIC Webcaches (307) for storage. The buffering 
component at the intermediate node stores the decapsulated HTTP request in buffer 
memory, and opens a file (or database record) tagged with the source socket (source IP 
address and TCP port number) and the destination socket (destination IP address and TCP 
port number) specified in the decapsulated HTTP request. The tagged file (or database 
record) would normally be on the storage device(s)used by each PIC Webcache interfaced 
with the intermediate node. The tagged file awaits the arrival of the contents of the 
relevant HTTP response to be delivered later by the buffering component 

Upon receipt at the hub node of an HTTP response, the hub node (303 in FIG 3 A) 
transmits the HTTP response in the outbound broadcast channel (316 in FIG. 3). If a 
browser running onaend-usernode interfaced witharemote terminal originated theHTTP 
request that generated the HTTP response, the HTTP response is received in the outbound 
channel by that remote terminal, forwarded to the PIC Webcache in the normal manner, 
and delivered by the PIC Webcache, operating as a proxy server cache, to the requesting 
browser. The seconda^monitoringcomponentatthe intermediate node forwards through 
a second communications path (31 1) every HTTP response inthe outbound channel to the 
buffering component running on the intermediate node. If a browser running on an end- 
user node interfaced with a remote terminal did not originate the HTTP request that 
generated the HTTP response, the contents of the HTTP response are not passed to the 
browser upon receipt Ramer, me buffermg component on me mtermemate node exa^^ 
the HTTP response to determine the source and destination sockets and stores the contents 
of the HTTP response inthe file (or database record) previously tagged with those sockets 
(the source and destination sockets are reversed m me HTTP request as compared with the 
HTTP response). After receiving both the HTTP request and the HTTP response, the 
buffermgcomponentatmemteme^^ 

HTTP response, extract the URL identity from the HTTP request, and create a file (or 
database record) for the URL on the storage device(s) used by each PIC Webcache as if 
each PIC Webcache itself had cached the URL. To receive and store the HTTP response, 
the PIC system typically uses a local area network (3 1 8) and may use TCP port numbers 
allocated by end-user nodes interfaced with the intermediate node for the purpose of 
directly accessing and updating the PIC Webcache on the disk(s) of the end-user PCs. If 
the browser requests that URL in the future, the contents of the URL will already be in the 
PICWebcachesemngtoebrowser,andwMbed^ 
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In the event the browser running on an end-user node interfaced with an 
intermediate PIC component on a remote terminal did not originate the HTTP request that 
generated an HTTP response provided by the secondary monitoring component at the 
intermediate node to the buffering component at the intermediate node, and the buffering 
component atthe intermediate nodehasnotyetreceivedviaanencapsulatedUDPmessage 
from the hub node containing a copy of the HTTP request that triggered such HTTP 
response, the buffering component at the intermediate node stores the HTTP response in 
buffer memory, tagged by source socket and destination socket, until the correct 
(matchable sockets) HTTP request arrives via an encapsulated UDP message from the hub 
node. Upon receipt and decapsulation of the HTTP request, the buffering component can 
match 1he HTTP request with the correct HTTP response, extract the URL identity from 
the HTTP request, and create a file (or database record) for the URL on the storage 
device(s) used by a PIC Webcache as if the PIC Webcache itself had cached the URL and 
its contents. 

Third Embodiment : Buffering and PIC Webcache at intermediate node (TR: Socket 
Matching at IN) 

FIG. 4 illustrates the Passive Internet Cache embodiment with socket matching and 
PIC Webcache at an intermediate node in a star topology, dual channel network. FIG. 4A 
illustrates the distribution of PIC components in the third embodiment. Reference 
numerals are to FIG. 4 unless otherwise noted. 

A third embodiment of the Passive Internet Cache system in a star topology, dual 
channel network implements abuffering component (406) and aPIC Webcache (407) an 
intermediate node (417). This embodiment has the advantage of requiring only one 
instance of the secondary monitoring component, buffering component, and PIC Webcache 
to serve all end-user nodes on one or more local area networks (418) (or other local 
connectivity) interfaced withthe intermediate node, andprovidingimprovedresponsetime 
without the expense of have end-user nodes equipped with caching devices. Additionally, 
high performance memory, storage, and dedicated processors) can provide performance 
improvements by off-loading processing and storage requirements from the end-user 
nodes. Such a configuration is well-suited to a residential set-top box used as an 
intermediate node, with home PCs, appliances, security, and environmental systems as 
end-user nodes. TCP/IP is used in the local area network (or other connectivity) between 
the intermediate node and the end-user nodes. 

The third embodiment of the Passive Internet Cache system implements a primary 
monitoring (401) and an encapsulation component (402) at a hub node, a secondary 
momtormgcomponent(404),decapsdationcomponent(405),bufferm^ 
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and PIC Webcache (407) at a comptrter or set-top box that is interfaced with, or is an 
integral part of, a remote terminal (409) and is also interfaced with a local area network 
(418) (or other connectivity) that serves one or more end-user nodes. The end-user nodes 
may also communicate directly with a remote terminal for communications unrelated to 
the PIC system. The PIC Webcache in this embodiment may be configured as a proxy 
server cache (i.e., browsers configured to use a TCP port for HTTP that is uniquely 
allocated to the PIC Webcache) or as a caching appliance (i.e., browsers need not be 
configured to use a TCP port for HTTP that is uniquely allocated to the PIC Webcache, 
and would normally use well-known TCP port 80). The Web browser on the end-user 
node must be configured for proxy server cache if the proxy configuration is implemented. 
If the PIC Webcache is configured as a caching appliance, it is not necessary to configure 
browsers on end-user nodes to use a caching appliance, since using well-known TCP port 
80 in the destination socket directs HTTP requests through the caching appliance. The 
primary monitoring component (401) and the encapsulation component (402) of the PIC 
system at the hub node function (403 in FIG. 4A) as described for the first and second 
embodiments. In addition, the secondary monitoring component (404), and the 
decapsulation component (405), at the intermediate node communicate and function as 
described in the second embodiment. The buffering component (406) at the intermediate 
node communicates with disk drive(s) (412) or other read/write storage device(s) 
associated with the intermediate node that are used by one or more PIC Webcaches (407) 
at the intermediate node for storage. The buffering component at the intermediate node 
stores the decapsulated HTTP request in buffer memory, and opens a file (or database 
record) tagged with the source socket (source IP address and TCP port number) and the 
destination socket (destination IP address and TCP port number) specified in the 
decapsulated HTTP request. Multiple PIC Webcaches may be associated with the 
intermediate node to enable load-sharing or redundancy. The tagged file (or database 
record) would normally be on the storage device(s) used by the PIC Webcache at the 
intermediate node. The tagged file (or database record) awaits the arrival of the contents 
of the relevant HTTP response to be delivered later by the buffering component 

Uponreceipt at the hub node of an HTTP response, Ihehub node (403 in FIG 4A) 
transmits the HTTP response in the outbound broadcast channel (416 in FIG. 4). If a 
browser running on a end-user node interfaced through a PIC-equipped intermediate node 
to a remote terminal originated the HTTP request that generated the HTTP response, the 
HTTP response is received in the outbound channel by that remote terminal, forwarded to 
the PIC Webcache in the normal manner, and delivered by the PIC Webcache, operating 
either as a proxy server cache or as a caching appliance, to the requesting browser. The 
secondary monitoring component at the intermediate node forwards through a second 
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communications path (411) every HTTP response in the outbound channel to the buffering 
component running on the intermediate node. If a browser running on an end-user node 
mterfacedthroughaPIC-eqmppedmtermediatenodetoaremotetermmd 
the HTTP request that generated the HTTP response, the contents of the HTTP response 
are not passed to the browser upon receipt. Rather, the buffering component on the 
intermediate node examines the HTTP response to determine the source and destination 
sockets and stores the contents of the HTTP response in the file (or database record) 
previously tagged with those sockets (the source and destination sockets are reversed in 
the HTTP request as compared with the HTTP response). After receiving both the HTTP 
request and the HTTP response, the buffering component at the intermediate node can 
match the HTTP request with the correct HTTP response, extract the URL identity from 
the HTTP request, and create a file (or database record) for the URL on the storage 
device(s) used by the PIC Webcache(s) at the intermediate node as if the relevant PIC 
Webcache itself had cached the URL. To receive and store the HTTP response, the PIC 
system does not obtain or use a TCP port number allocated by end-user nodes interfaced 
with the intermediate node. If a browser on an end-user node requests that URL in the 
future, the contents of the URL will already be in the PIC Webcache, and will be delivered 
from the PIC Webcache to the browser. 

In the event the browser running on an end-user node interfaced with a remote 
terminal did not originate the HTTP request that generated an HTTP response provided by 
the secondary monitoring component at the intermediate node to the buffering component 
at the intermediate node, and the buffering component at the intermediate node has not yet 
received, via an encapsulated UDP message from the hub node, a copy of the HTTP 
request that triggered such HTTP response, the buffering component at the intermediate 
node stores the HTTP response in buffer memory, tagged by source socket and destination 
socket, until the correct (matchable sockets) HTTP request arrives via an encapsulated 
UDP message from the hub node. Upon receipt and decapsulation of the HTTP request, 
the buffering component can match the HTTP request with the correct HTTP response, 
extract the URL identity from the HTTP request, and create a file (or database record) for 
the URL on the storage device(s) used by the PIC Webcache(s) on the intermediate node 
as if the relevant PIC Webcache itself had cached the URL and its contents. 
Fourth Embodiment : Split Buffering (hub and end-user nodes) and PIC Webcache at end- 
user node (TR: Socket Matching at hub node ("HN")) 

FIG. 5 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node and with secondary buffering and PIC Webcache at an end-user nodeinastar 
topology, dual channel network. FIG. 5A illustrates the distribution of PIC components 
in the fourth embodiment Reference numerals are to FIG. 5 unless otherwise noted. 
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A fourth embodiment of the Passive Internet Cache system in a star topology, dual 
channel network implements a primary monitoring component (501), an encapsulation 
component (502), and aprimary buffering component (519) at ahub node, an initial socket 
matching function in the primary buffering component (519) at the hub node, and a 
secondary monitoring component (504), a secondary buffering component (506), a 
decapsulation component (505), and a PIC Webcache (507) at an end-user node (508 in 
FIG. 5A). In the context of a star topology, dual channel network with a large number of 
remote terminals, the use of a primary buffering component at the hub node permits a 
smaller buffer memory, lower performance storage, and a lower performance processor to 
be used by the secondary buffering component at the end-user node. Assuming a remote 
terminal can output all HTTP responses by the use of configuration settings, the typical 
PIC components at the end user node are software modules installed on an end-user PC 
and, as such, require no hardware investment to implement. The PIC Webcache is 
configured as a proxy server cache and the Web browser on the end-user computer is 
configured to use such proxy server cache. The primary monitoring component (501) at 
thehub node monitors all inbound channels transmitted from all the remote terminals (509, 
5 1 3) to the hub node . The primary monitoring component (501) copies all HTTP requests 
from the monitored inbound channels (514, 515), and forwards each HTTP request to the 
encapsulation component (502). The encapsulation component creates a UDP packet 
containing the HTTP request using a broadcast IP address and port as described above, and 
forwards the encapsulated packet to the primary buffering component (519) at the hub 
node. The primary buffering component (519) stores the encapsulated HTTP request in 
buffer memory, tagged with the source socket (source IP address and TCP port number) 
and the destination socket (destination IP address and TCP port number) specified in the 
HTTP request The primary buffering component at the hub node examines the source and 
destination sockets in the IP packet containing the HTTP response and matches them with 
the destination and source sockets in the appropriate previously UDP-encapsulated IP 
packet containing the HTTP request. Upon receipt at the hub node of an HTTP response, 
me primary monitoring component (501) provides the HTTP response to the primary 
buffering component (519) at the hub node. The HTTP response is not immediately 
broadcast by the hub node in the outbound channel. The primary buffering component 
(519) at the hub node examines the source and destination sockets in the IP packet 
containing the HTTP response and matches them with the destination and source sockets 
inthecorresponding, previously UDP-encapsulated IP packet containmg me HTTP request 
(the source and destination sockets are reversed in the HTTP request as compared with Ihe 
HTTP response). The primary buffering component (519), soon after providing the 
encapsulated HTTP request to the outbound channel (516), provides the corresponding 
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HTTP response to the outbound channel (516) for transmission to the remote terminals 
(509, 513). 

The secondary monitoring component (504) at the end-user node (508, inFIG. 5A) 
communicates through a network interface on the end-user node with the remote terminal 

(509) . The secondary monitoring component (504) also communicates through a first 
communications path (510) with the decapsulation component (505), and thence with the 
secondary buffering component (506), at the end-user node. The secondary monitoring 
component (504) copies from the remote terminal through the first communications path 

(510) to the decapsulation component (505) on the end-user node all encapsulated UDP 
packets, and through a second communications path (511) to the secondary buffering 
component on the end-user node all HTTP packets, received by the remote terminal, not 
just those packets with an IP destination address of the end-user node. When the 
secondary monitoring component (504) on the end-user node receives a UDP packet 
containing an encapsulated HTTP request, it provides through a first portion of the first 
communications path (510) such packet to the decapsulation component. The 
decapsulation componentremovesmeUDPencap^^ 

through a second portion of the first communications path (5 1 0) each decapsulated HTTP 
request to the buffering component at the end-user node. The buffering component at the 
end-user node communicates with disk drive(s) or other read/write storage device(s) 
associated with the end user node that are used by the PIC Webcache for storage. The 
buffering component stores the decapsulated HTTP request in buffer memory, and opens 
a file (or database record) tagged with the source socket (source IP address and TCP port 
number) and the destination socket (destination IP address and TCP port number) specified 
in the decapsulated HTTP request. The tagged file (or database record) would normally 
be on the storage device(s) used by the PIC Webcache. The tagged file (or database 
record) awaits the arrival of the contents of the relevant HTTP response from the buffering 
component 

If a browser running on a end-user node interfaced with a remote terminal 
originated the HTTP request that generated the HTTP response, the HTTP response is 
received in the outbound channel by that remote terminal, forwarded to the PIC Webcache 
in the normal manner, and delivered by the PIC Webcache, operating as a proxy server 
cache, to the requesting browser. The secondary monitoring component (504) at the end- 
user node also forwards through the second communications path (511) every HTTP 
response in the outbound channel to the secondary buffering component (506) nnining on 
the end-user node. If a browser running on an end-user node interfaced with a remote 
terminal did not originate the HTTP request that generated the HTTP response, the 
contents of the HTTP response are not passed to the browser upon receipt Rather, the 
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secondary buffering component on the end-user node examines the HTTP response to 
determine the source and destination sockets and stores the contents of the HTTP response 
in the file (or database record) previously tagged with those sockets (the source and 
destination sockets are reversed in the HTTP request as compared with the HTTP 
response). After receiving both the HTTP request and the HTTP response, the secondary 
buffering component at the end-user node can match the HTTP request with the correct 
HTTP response, extract the URL identity from the HTTP request, and create a file (or 
database record) for the URL on the storage device(s) (512) used by the PIC Webcache 
(507) as if the PIC Webcache itself had cached the URL. To receive and store the HTTP 
response, the PIC system does not obtain or use a TCP port number allocated by the end- 
user node. If the browser requests that URL in the future, the contents of the URL will 
already be in the PIC Webcache serving the browser, and will be delivered instantly from 
the PIC Webcache to the browser. 

Fifth Embodiment : Split Buffering (hub node and intermediate node) and PIC Webcache 
at end-user node (TR: Socket Matching at HN) 

FIG. 6 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node, with secondary buffering at an intermediate node, and with PIC Webcache 
at an end-user node in a star topology, dual channel network. FIG. 6A illustrates the 
distribution of PIC components in the fifth embodiment. Reference numerals are to FIG. 

6 unless otherwise noted. 

A fifth embodiment of the Passive Internet Cache system in a star topology, dual 
channel network implements a primary monitoring component (601), an encapsulation 
component (602), and a primary buffering component (619) at the hub node, an initial 
socket matching function in the primary buffering component at the hub node, and a 
secondary monitoring component (604), a secondary buffering component (606), and a 
decapsulation component (605) at an intermediate node, and a PIC Webcache (607) at an 
end-user node. Inmecontextofastartopology,dudchflmelnetworkwimalarge number 
of remote terminals, the use of a primary buffering component at the hub node permits 
smaller buffer memory and lower performance storage and processor to be used by the 
secondary buffering component at the intermediate node. The PIC Webcache is 
configured as a proxy server cache and the Web browser on the end-user computer is 
configured to use such proxy server cache. The primary monitoring component at the hub 
node monitors all inbound channels transmitted from all the remote terminals to the hub 
node. The primary monitoring component (601) copies all HTTP requests from the 
monitored inbound channels, and provides each HTTP tequest to the encapsulation 
component (602) where, as in the fourth embodiment, each HTTP request is encapsulated 
in aUDP packet with a broadcast IP address and port and is then forwarded to the primary 
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buffering component(619)atthehubnode. Theprimary buffering component (619) stores 
the encapsulated HTTP request in buffer memory at the hub node, tagged with the source 
socket (source IP address and TCP port number) and the destination socket (destination IP 
address and TCP port number) specified in the HTTP request Upon receipt at the hub 
node of an HTTP response, the primary monitoring component (601) provides me HTTP 
response to the primary buffering component (619) at the hub node. The HTTP 
response is not immediately broadcast by the hub node in the outbound channel. The 
primary buffering component (619) at the hub node examines the source and destination 
sockets in the IP packet containing the HTTP response and matches them with the 
destination and source sockets in the associated, previously UDP-encapsulated IP packet 
containing the HTTP request (the source and destination sockets are reversed in the HTTP 
request as compared with the HTTP response). AfterreceivingboththeHTTPrequestand 
the HTTP response, the primary buffering component (619) provides the HTTP request to 
the outbound channel (616) for transmission in the outbound channel using a broadcast IP 
address and UDP port (or other suitable protocol, address, and port) monitored by all 
remote terminals that receive such outbound channel and are interfaced with local PIC 
components. The primary buffering component (619), soon after providing the 
encapsulated HTTP request to the outbound channel (616), provides the corresponding 
HTTP response to the outbound channel (616) for transmission to the remote terminals 
(609,613). 

The secondary monitoring component (604) at the intermediate node (617 m FIG. 
6A) communicates through a network interface on the intermediate node with the remote 
terminal. The secondary monitoring component (604) also communicates with the 
decapsulation component (605), and with the secondary buffering component (606), at the 
intermediate node. The secondary monitoring component (604) copies from the remote 
terminal (603) and forwards through a first portion of a first communications path (610) 
to the decapsulation component (605) on the intermediate node all encapsulated UDP 
packets, and through a second communications path (611) to the secondary buffering 
component on the intermediate node all HTTP packets, received by the remote terminal, 
not just those packets with an IP destination address of the intermediate node or of end- 
user nodes served by that remote terminal. When the secondary monitoring component 
(604) on the intermediate node receives a UDP packet containing an encapsulated HTTP 
request, it provides such packet to the decapsulation component through the first portion 
of the first communications path (610). The decapsulation component removes the UDP 
encapsulation ^decapsulation''), and forwards through a second portion of the first 
communications path (61 1) each decapsulated HTTP request to the secondary buffering 
component (606) at the intermediate node. The secondary buffering component (606) at 
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the intermediate node communicates with disk drive(s) (612) or other read/write storage 
device(s) associated with each end user node that are used by one or more end-user nodes' 
PIC Webcaches for storage. The secondary buffering component stores the decapsulated 
HTTP request in buffer memory, and opens a file (or database record) tagged with the 
source socket (source IP address and TCP port number) and the destination socket 
(destinationIP address andTCP portnumher) specified in the decapsulated HTTP request. 
The tagged file (or database record) would normally be on the storage device(s) used by 
each PIC Webcache interfaced with the intermediate node. The tagged file (or database 
record) awaits the arrival of the contents of the relevant HTTP response from the buffering 
component. 

If a browser running on a end-user node interfaced with a remote terminal 
originated the HTTP request that generated the HTTP response, the HTTP response is 
received in the outbound channel by that remote terminal, forwarded to each PIC 
Webcache in the normal manner, and delivered by the PIC Webcache associated with an 
end-user node, operating as a proxy server cache, to the requesting browser. The 
secondary monitoring component (604) at the intermediate node also forwards through the 
second communications path (61 1) every HTTP response in the outbound channel to the 
secondary buffering component (606) running on the intermediate node. If a browser 
running on an end-user node interfaced with a remote terminal did not originate the HTTP 
request that generated the HTTP response, the contents of the HTTP response are not 
passed to the browser upon receipt. Rather, the secondary buffering component on the 
intermediate node examines the HTTP response to determine the source and destination 
sockets and stores the contents of the HTTP response in the file (or database record) 
previously tagged with those sockets (the source and destination sockets are reversed in 
the HTTP request as compared with the HTTP response). After receiving both the HTTP 
request and the HTTP response, the secondary buffering component at the intermediate 
node can match the HTTP request with the correct HTTP response, extract the URL 
identity from the HTTP request, and create a file (or database record) for the URL on the 
storage device(s) used by each PIC Webcache as if each PIC Webcache itself had cached 
the URL. To receive and store the HTTP response, the PIC system typically uses a local 
area network (61 8) and may use a TCP port number allocated by an end-user node for the 
purpose of directly accessing the disk area of the PIC Webcache on the end-user node. If 
a browser requests that URL in the future, the contents of the URL will already be in the 
PICWebcacheservmgmebrowser.andwiUbedeUveredinstantlyfromthePICWebcache 

to the browser. 

Qivrt. Embodiment; Split Buffering (hub node and intermediate node) and PIC Webcache 
at intermediate node (TR: Socket Matching at HN) 
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FIG. 7 illustrates the Passive Internet Cache embodiment with socket matching at 
the hub node and with PIC Webcache at an intermediate node in a star topology, dual 
channel network. FIG. 7A illustrates the distribution of PIC components in the sixth 
embodiment. Reference numerals are to FIG. 7 unless otherwise noted. 

Asixth embodiment ofthe Passive Internet Cache system in a star topology, dual 
channel network implements a primary monitoring component (701), an encapsulation 
component(702),andaprimary buffering 

matching function in the primary buffering component (719) at the hub node, and a 
secondary monitoring component (704), a secondary buffering component (706), a 
decapsulation component (705), and a PIC Webcache (707) at an intermediate node (7 1 7 
inFIG 7A) mthecontextofastartopology.dualchamelnetworkvvithalargenumber 
of remote terminals, the use of a primary buffering component at the hub node permits 
smaller buffer memory and lower performance storage and processor to be used by the 
secondary buffering component at the intermediate node. This embodiment has the 
advantage of requiring only one instance of the secondary monitoring component 
buffering component, andPIC Webcache to serve all end-usernodes on one ormore local 

area networks (or other local connectivity) interfaced with the intermediate node, and 
providing improved response time without the expense of have end-user nodes equipped 
with caching devices. Additionally, high performance memory, storage, and dedicated 
processor can provide performance improvements by off-loading processing and storage 
requiromentsfrommeend-usernode^^ 

with a remote terminal for communications unrelated to the PIC system. The PIC 
Webcache in this embodiment may be configured as a proxy server cache (i.e., browsers 
configured to use a TCP port for HTTP that is uniquely allocated to the PIC Webcache) 
or as a caching appliance (i.e., browsers need not be configured to use a TCP port for 
HTTP that is uniquely allocated to the PIC Webcache, and would normally use well- 
known TCP port 80). The Web browser on the end-user node must be configured for 
proxy server cache if the proxy configuration is implemented. If the PIC Webcache is 
configured as a caching appliance, it is not necessary to configure browsers on end-user 
nodestousethecachmgapphance^^^ 
socket directs HTTP requests through the caching appliance. 

Theprimarymonitoringcomponent(701), the primary buffering component (719), 
and the encapsulation component (702) ofthe PIC system at the hub node function as 
described above for the fourth and fifth embodiments. In addition, the secondary 
, m0 nitoring component (704), the decapsulation component (705), first communications 
path (710), and second communications path (711) at the intermediate node function as 
described above for the fifth embodiment. In the sixth embodiment, the secondary 
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buffering component (706) atmemtennemate node conm^^ 
or other read/write storage device(s) located at the intermediate node that are used by one 
or more PIC Webcaches at the intermediate node for storage. The secondary buffering 
component (706) at the intermediate node stores the decapsulated HTTP request in buffer 
memory, and opens a file (or database record) tagged with the source socket (source IP 
address and TCP port number) and the destination socket (destination IP address andTCP 
port number) specified in the decapsulated HTTP request. The tagged file (or database 
record) would normally be on the storage device(s) used by a given PIC Webcache at the 
intermertate node. MmtiplePIC Webcaches m 

to enable load-sharing or redundancy. The tagged file awaits the arrival of the contents of 
the relevant HTTP response from the buffering component. 

If a browser running on a end-user node interfaced with a remote terminal 
originated the HTTP request that generated the HTTP response, the HTTP response is 
received in the outbound channel by that remote terminal, forwarded to the relevant PIC 
Webcache in the normal manner, and delivered by the PIC Webcache, operating either as 
a proxy server cache or as a cascaded caching appliance, to the requesting browser. The 
secondary monitoring component at the intermediate node forwards every HTTP response 
mmeomboundchanneltomesecondarybuffermgcomponentrun^ 
node Ifabrowserrunrungonanend-usernodemterfacedwimaremotetermm^ 
originate the HTTP request that generated the HTTP response, Hie contents of the HTTP 
response are not passed to the browser upon receipt. Rather, the secondary buffering 
componentonmemtermematenodeexammesmeHTTPresponsetodete™ 
and destination sockets and stores the contents of the HTTP response in the file (or 
database record) previously tagged with those sockets (the source and destination sockets 
are reversed in the HTTP request as compared with the HTTP response). After receiving 
both the HTTP request and the HTTP response, the secondary buffering component at the 
intermediate node can match the HTTP request with the correct HTTP response, extract 
the URL identity from the HTTP request, and create a file (or database record) for the URL 
on the storage device(s) used by one or more PIC Webcaches at the intermediate node as 
if the PIC Webcache itself had cached the URL and its contents. To receive and store the 
HTTP response, the PIC system does not obtain or use a TCP port number allocated by 
end-user nodes interfaced with the intermediate node. If a browser on an end-user node 
requeststhatlJPXmmefoture,mecontenteofmeURLw^ 
Webcache, and will be delivered from the PIC Webcache to the browser. 
s,,v«nth Rmhodiment: Buffering and PIC Webcache at end-user node (RO: Socket 
Matching at EUN) 

nG.gillustratesthePassivelnternet Cache embodiment with socket matehmg and 
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PIC Webcache at an end-user node in a star topology, single channel network. FIG. 8A 
illustrates the distribution of PIC components in the seventh embodiment. Reference 
numerals are to FIG. 8 unless otherwise noted. 

AseventhembodimentofthePICsystem is structurally and functionally identical 
the first embodiment, except the remote terminal is receive only and cannot initiate HTTP 
requests. The inability to initiate HTTP requests, or other return channel messages, does 
not prevent or impair the operation of the components of the PIC system. The PIC 
Webcache built at an end-user node reflects the HTTP requests initiated by other end-user 
nodes that have an inbound channel. 

F, >hth Embodiment : Buffering at intermediate node and PIC Webcache at end-user node 

(RO: Socket Matching at IN) 

FIG. 9 illustrates Ihe Passive Internet Cache embodiment with socket matching at 
anintermediate node and with PIC Webcache at an end-user node in a star topology, single 
channel network. FIG. 9A illustrates the distribution of PIC components in the eighth 
embodiment. Reference numerals are to FIG. 9 unless otherwise noted. 

An eighth embodiment of the PIC system is structurally and functionally identical 
the second embodiment, except the remote terminal is receive only and cannot initiate 
HTTP requests. The inability to initiate HTTP requests, or other return channel messages, 
does not prevent or impair the operation of the components of the PIC system. The PIC 
Webcache built at an end-user node reflects the HTTP requests initiated by other end-user 
nodes that have an inbound channel. 

KTmtf, Embodiment. Buffering and PIC Webcache at intermediate node (RO: Socket 
Matching atlN) 

FIG. 10 illustrates the Passive Internet Cache embodiment with socket matching 
and PIC Webcache at an intermediate node in a star topology, single channel network 
FIG. 10A illustrates the distribution of PIC components in the ninth embodiment 
Reference numerals are to FIG. 10 unless otherwise noted. 

AmnmembodimentofthePIC systemis structuraUy and functionally identical the 
third embodiment, except the remote terminal is receive only and cannot initiate HTTP 
requests. The inability to initiate HTTP requests, or other return channel messages, does 
not prevent or impair the operation of the components of the PIC system. The PIC 
Webcache built at an intermediate node reflects the HTTP requests initiated by other end- 
user nodes that have an inbound channel. 

T.nth Embodiment : Split Buffering (hub and end-user nodes) and PIC Webcache at end- 
user node (RO: Socket Matching at HN) 

FIG 11 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node and with secondary buffering and PIC Webcache at an end-user node in 
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a star topology, single channel network. FIG. 11A illustrates the distribution of PIC 
componentsinthetenthembodiment. Reference numerals are to FIG. 11 unless otherwise 

n0ted AtenthembodimentofthePICsystem^^ 

fourth embodiment, except the remote terminal is receive only and cannot initiate HTTP 
requests The inability to initiate HTTP requests, or other return channel messages, does 
not prevent or impair the operation of the components of the PIC system. The PIC 
Webcachebuiltatanend-m^ 
nodes that have an inbound channel. 

pwnth Embodiment: Split Buffering (hub node and intermediate node) and PIC 
Webcache at end-user node (RO: Socket Matching at HN) 

FIG 12 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node, with secondary buffering at an intermediate node, and with PIC 
Webcache at an end-user node in a star topology, single channel network. FIG. 12A 
illustrates the distribution of PIC components in the eleventh embodiment. Reference 
numerals are to FIG. 12 unless otherwise noted. 

An eleventh embodiment of the PIC system is structuraUy and functionally 
identical the fifth embodiment, except the remote terminal is receive only and cannot 
initiate HTTP requests. The inability to initiate HTTP requests, or other return channel 
messages, does notprevent or impair the operation of the components of the PIC system. 
The PIC Webcache built at an end-user node reflects the HTTP requests initiated by other 
end-user nodes that have an inbound channel. 

jwslfih Fmhodiment: Split Buffering (hub node and intermediate node) and PIC 
Webcache at intermediate node (RO: Socket Matching at HN) 

FIG 13 illustrates the Passive Internet Cache embodiment with socket matching 
at the hub node and with secondary buffering and PIC Webcache and at an intermediate 
node inastartopology.singlechannel network. FIG. 13A illustrates the distribution of 
PIC components in the twelfth embodiment. Reference numerals are to FIG. 13 unless 

otherwise noted. . 

A twelfth embodiment of the PIC system is structurally and functionally identical 

thesixmembodiment,exceptmeremotetennindisrece^ 

requests. The inability to initiate HTTP requests, or other return channel messages, does 
not prevent or impair the operation of the components of the PIC system. The PIC 
Webcache built at an intermediate node reflects the HTTP requests initiated by other end- 
user nodes that have an inbound channel. 

For simplicity, in the embodiments that do not allocate TCP ports, if a browser 
running on an end-user node interfaced with a remote terminal originated the HTTP 
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request that generated a given HTTP response, aPIC system wouldnormally be configured 
so that the same HTTP request after being decapsulated from a UDP message, after receipt 
of the socket-matched HTTP response, causes an overwrite of the URL in the PIC 
Webcache that was already written in response to the HTTP response addressed directly 

5 to that end-user node's IP address and TCP port number (rather than through the PIC 
system). Such an implementation is said to have "exhaustive writing" of HTTP requests 
received by the PIC buffering component through UDP messages (i.e., does not need to 
recognize local addresses before writing the URL processed through the PIC system). 
Alternatively, a PIC buffering component on an end-user node can be designed for 

10 "selective writing" so that it does not write any HTTP request received by the PIC 
monitoring component through UDP messages to the PIC Webcache if the destination IP 
address of the HTTP response is that of the node on which the PIC Webcache is running. 
In case of "selective writing", the normal dialog of an HTTP request and an HTTP 
response will cause the requested URL to be written to the browser or cache that originated 

15 the HTTP request 

If the necessary decryption keys are available, a PIC system can work with 
encryptedHTTP messages. IfencryptedHTTP messages are exchanged, and the necessary 
decryption key is not available to a PIC system, the PIC system is unable to use (or 
possibly detect) HTTP messages that are encrypted. In all embodiments ofthe PIC system, 
20 encrypted payloads are simply handled as any other message, Le. cached in the encrypted 
form if TCP/IP header information is available and HTTP commands are decipherable, or 
discarded if not. Independently ofthe PIC system components, encrypted HTTP messages 
are processed in a normal manner, so that a browser sending an encrypted HTTP request 
can still receive an encrypted HTTP response. 
25 The return channel from a hub node through one or more monitoring components, 

encapsulating component, decapsulating component, one or more buffering components, 
to each PIC Webcache can also carry UDP messages that can be used to control HTTP 
content cached by a PIC Webcache based on the URL in an HTTP request or the source 
IP address of an HTTP response. Such access control can be used to permit or prevent 
30 cachmgofURLsandmehcontentmaPICWebcachemordertoimplemem 

authorization system, or simply to block content from objectionable network domains, 
hosts, etc. With reference to FIG. 16, implementation of access control using a PIC 
systemrequiresacontentaumorizahra^ 

with the hub node (1620), preparation of content authorization messages addressed to one 
35 or more buffering components associated with remote terminals by the content 
authorization program, encapsulation of the authorization control messages by the 
encapsulating component (1602) at a hub node, transmission of the encapsulated 
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authorization control messages in the outbound channel (1616), delivery of the 
decapsulated authorization control messages to the each buffering component in me same 
manner as delivery of decapsulated HTTP requests as described above, and execution of 
the authorization control message by an intermediate node content authorization 
component (1621) associated with a buffering component (1606) and/or by an end-user 
node content authorization component (1622) associated with a PIC Webcache (1607). 
The authorization control message determines what URLs are cached in a given PIC 
Webcaches; messages exchanged between the buffering component (1606) and a given 
intermediate node or end-usernode content aumorizationcomponentdeterminewhatURLs 
areblockedfromcaching. Contentauthorizationcomponen1s(1621, 1622)associatedwim 
or interfaced with a remote terminal prevent a PIC Webcache from caching a URL or 
source IP address that is specified as unauthorized ("blocked") for a given PIG Webcache. 
Content authorization through a content authorization program and database is known in 
the art, but its use in conjunction with a PIC system is novel. A content authorization 
component at different end-user nodes canbeused to create end-user PIC Webcaches with 
different content, but associated with a single intermediate node (1617) and intermediate 
node content authorization component (1621). By using a content authorization 
component (1621) at an intermediate node (1617), an additional point of content control 
is introduced. Content authorization at an intermediate node PIC Webcache (not 
illustrated) canbe implemented in networks mat have some end-user nodes equipped with 
PIC Webcaches and some that are not equipped with PIC Webcaches. Different end-user 
nodes can also be assigned to use different PIC Webcaches, and thereby have access to 
different content. 

The buffering component at an intermediate node or at an end-user node can 
contain a program that monitors whether the payload of an HTTP request or HTTP 
response has errors based on common error checking methods, such as packet sequence 
number continuity. A given HTTP message may require multiple TCP/IP packets for 
transmission. With reference to FIG. 17, TCP inserts a sequence number into each packet 
used to transmit a given HTTP message. For a given HTTP response provided to a PIC 
buffering component associated with or interfaced with a remote terminal, only one 
payload of a packet with a given TCP sequence number is needed. If a packet stream for 
a given HTTP request contains more than one packet with the same TCP sequence number 
(upper portion of FIG. 17), the buffering component discards packets with duplicate TCP 
sequencenumbers. Sucherrorcheckm^^ 
; in normal TCP/IP protocol handshakes. By reference to the lower portion of FIG. 17, a 
PIC buffering component associated with or interfaced with a remote terminal can be 
configured to discard HTTP messages determined by the buffering component to have 



35 



PCT/US01/15575 

WO 01/88761 

missing TCP sequence numbers. If the remote terminal associated with or interfaced with 
a buffering component has inbound channel capability, and the buffering component 
determines that an HTTP response has a corrupted payload, the buffering component can 
(optionally) use the URL in the decapsulatedHTTP request to generate an HTTP request 
from the end-user node (using normal TCP/IP procedures) for the URL at issue, and obtain 
another HTTP response from the relevant Webserver. 

Taking an "end to end" perspective of the handling of UDP messages and HTTP 
responses by PIC components, in PIC embodiments without socket-matching at a hub 
node, for UDP messages, a fust end-to-end communications path exists through a 
primary monitoring component and encapsulating component at ahub node, then 
through an outbound channel from the hub node, then through a remote terminal to a 
secondary monitoring component and decapsulating component to a buffering 
component; for HTTP responses, a second end-to-end communications path exists from 
external server computers or traditional caches through the outbound channel of the hub 
node, then through the remote terminal to the secondary monitoring component, and 
then to the buffering component In PIC embodiments with socket-matching at a hub 
node, for UDP messages, a first end-to-end communications path exists through a 
primary monitoring component, encapsulating component, and primary buffering 
component at a hub node, through the outbound channel from the hub node, then 
through a remote terminal to a secondary monitoring component and decapsulating 
component, then to a secondary buffering component; for HTTP responses, a second 
end-to-end communications path exists from external server computers or traditional 
caches through Ihe primary buffering component at a hub node, then through the 
outbound channel from the hub node, then through a remote terminal to the secondary 
i monitoring component and then to the secondary buffering component. 

Those skilled in the art also will readily appreciate that many modifications to the 
invention are possible within me scope of me mvention. Anomer alterative ^ 
to provide redundancy, wouldinclude more than one PIC buffering component associated 
with a given end-user node. For mixed populations of end-user nodes, an intermediate 
node PIC Webcache can be implemented in networks that have some end-user nodes 
equipped with PIC Webcaches and some that are not equipped with PIC Webcaches. 
Accordingly, the scope of the invention is not intended to be limited to the preferred 
embodiments described above, but only by the appended claims. 
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CLAIMS 

We claim: 

1 . A system of encapsulation and passive listening, comprising: 

a means hosted on a hub node of a network by which a message from a first network 
5 node to saidhub node is encapsulated in a broadcast or multicast message and transmitted 
to one or more other network nodes unable to receive the original transmission of said 
message from said first network node to said hub node, 

a means associated with each of said one or more other network nodes of receiving, 
unencapsulating, and buffering said message when it arrives, and 
10 a means of storing the contents of the decapsulated and buffered message in cache 

memory or storage accessible by an end-user at each of said one or more other network 
nodes. 

2. A system of encapsulation and passive listening, comprising: 

a means hosted on a hub node of a network by which a message from a first network 
15 node to said hub node is selected for encapsulation based on one or more criteria, such as 

being an HTTP request or being addressed to a certain network address or socket, then 

encapsulated in a broadcast or multicast message and transmitted to one or more other 

network nodes unable to receive the original transmission of said message from said first 

network node to said hub node, 
20 a means associated with each of said one or more other network nodes of receiving, 

unencapsulating, and buffering said message when it arrives, and 

a means of storing the contents of the decapsulated and buffered message in cache 

memory or storage accessible by an end-user at each of said one or more other network 

nodes. 

25 3. A system of encapsulation and passive listening, according to claim 1 or 2, wherein said 

message transmitted from said hub node to said one or more other network nodes is 

encapsulated in User Datagram Protocol or a transport layer, connectionless protocol 

substantially equivalent to User Datagram Protocol. 

4. A system of socket matching, comprising: 
30 a means hosted on a hub node of a network by which an HTTP request from a first 

network node to said hub node is forwarded to a server computer and by which means a 
copy of said HTTP request is also transmitted to one or more other network nodes unable 
to receive the original transmission of said HTTP request from said first network node to 
said hub node, and by which means a copy of an HTTP response sent by said server 
35 computer in response to said HTTP request is transmitted to said first network node and 
to said one or more other network nodes, 

a means, associated with or interfaced with each of said one or more other network 
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nodes, of receiving and buffering said HTTP request when it arrives, and of receiving and 
buffering said HTTP response when it arrives, in buffer memory associated with or 
interfaced with each of said one or more other network nodes, 

a means, associated with or interfaced with each of said one or more other network 
nodes of matching the source socket and destination socket of abuffered HTTP request 
withthe source socket and destmation socket ofabuffered HTTP response (the sour^ 
destination sockets are reversed in the HTTP request as compared with the HTTP 
response) sent by the server computer in response to said HTTP request and received 
before or after receipt of said HTTP request, and 

a means of storing under the URL specified in the matching HTTP request the 
contentsofthe matched HTTP response in cache memory accessibleto an end-user node, 
which end user node is associated with or interfaced with one of said one or more other 
network nodes. 

5 A system of socket matching, comprising: 

a means hosted on a hub node of a network by which an HTTP request from a first 
network node to said hub node is forwarded to a server computer and by which means a 
copy of said HTTP request is buffered at said hub node until such time as an HTTP 
response sent by said server computer in response to said HTTP request is received, 
buffered, and matched as described below at said hub node, 

ameans hosted on said hub node of matching the source socket and destination socket 
of said buffered HTTP request with the source socket and destination socket of said 
buffered HTTP response (the source and destination sockets are reversed in the HTTP 
request as compared with the HTTP response), 

a means hosted on said hub node of transmitting a matched HTTP response and the 
matching HTTP request to one or more other network nodes unable to receive the original 
transmission of said HTTP request from said first network node to said hub node, 

a means, associated with or interfaced with each of said one or more other network 
nodes of receiving and buffering said HTTP request when it arrives, and of receiving and 
buffering said HTTP response when it arrives, in buffer memory associated with or 
) interfaced with each of said one or more other network nodes, 

a means, associated with or interfaced with each of said one or more other network 
nodes of matching the source socket and destination socket of abuffered HTTP request 
with the source socket and destination socket of a buffered HTTP response (the source and 
destination sockets are reversed in the HTTP request as compared with the HTTP 
5 response) sent by Ihe server computer in response to said HTTP request and received 
before or after receipt of said HTTP request, and 

a means of storing under the URL specified in said matching HTTP request the 
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contents of saidmatchedHTTP response in cache memory accessible to an end-user node, 
which end user node is associated with or interfaced with one of said one or more other 
network nodes. 

6. Asystem of socket matchmg,accordmg to claim4or5,wherem Transmission 
Protocol or a transport layer protocol other than Transmission Control Protocol that uses 
the network addressing and routing capabilities of Internet Protocol, or a protocol other 
thanHypertextTransportProtocolthat uses paired network layer addressing and transport 
layerportsinrequest/response,client/serverexchanges substantially equivalent suchuse 
in Hypertext Transport Protocol, is used. 

7. A system of socket matching, according to claim 4 or 5, wherein the network is a star 
topology network selected from the group consisting of very small aperture satelhte, 
multichannel multipoint distribution service, local multipoint distribution service, 
instructional television fixed service, digital television broadcasting, and digital 
cablecasting. 

8 A system of socket matching, according to claim 4 or 5, wherein each said copy of an 
HTTP request is encapsulated in a broadcast or multicast message before transmission 
from said hub node and is decapsdated upon receipt and prior to buffering at each of said 
one of more other network nodes. 

9 A caching system for a star topology network, comprising: 

ahubnodeofmestartopologynetworktoatreceivesHTTPrequestsfromoneormore 

remote terminals, which hub node is interfaced with at least one external server computer 
and transmits UDP datagrams, HTTP requests, and HTTP responses in an outbound 
channel from said hub node of the star topology network, and 

one or more intermediate or end-user nodes of said network that receive said UDP 
datagrams, HTTP requests, and HTTP responses and which one or more intermediate or 
end-user nodes are associated with or interfaced with a means for socket-matching HTTP 
requests and HTTP responses and for storing in an end-user accessible cache the contents 
of a given HTTP response under the URL extracted from a correctly matched HTTP 
request. 

10 A caching system for a star topology network, comprising: 

ahubnodeofthe star topology networkthatreceives HTTP requests fromoneormore 
remote terminals, which hub node is interfaced wilh at least one external server computer, 
has a first means for socket-matching, and transmits UDP datagrams, HTTP requests, and 
HTTP responses in an outbound channel from said hub node of the star topology network, 

^ on e or more intermediate or end-user nodes of said network that receive said UDP 
datagrams, HTTP requests, and HTTP responses and which one or more intermediate or 
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end-user nodes are associated with or interfaced with a second means for socket-matching 
HTTP requests and HTTP responses and for storing in an end-user accessible cache the 
contents of a given HTTP response under the URL extracted from a correctly matched 
HTTP request. 

1 1 . A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
server computers, and internal to the star topology network has associated with die hub 
node a primary monitoring component, an encapsulating component, and an outbound 
channel, 

a secondary monitoring component, a decapsulating component, and a socket- 
matching buffering component associated with one or more intermediate node or end-user 
nodes interfaced with a remote terminal in the star topology network, 

at least one global cache associated with said buffering component and an end-user 
node, or where said buffering component is associated with an intermediate node, said at 
least one global cache either associated with said buffering component, or associated with 
an end-user node and interfaced with said buffering component, 

communications paths for UDP and HTTP messages from the hub node through 
the outbound channel to each buffering component, 

ameans controlled by each associated or interfaced buffering component ofwriting 
files or database records in each associated or interfaced global cache, 

wherein each global cache is accessible by at least one end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange HTTP requests and HTTP responses with 
said hub node using the star network medium or a different telecommunications medium. 
12. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, a socket-matching 
primary buffering component, and an outbound channel, 

a secondary monitoring component, a decapsulating component, and a socket- 
matching secondary buffering component associated with one or more intermediate nodes 
or end-user nodes interfaced with a remote terminal in the star topology network, 

at least one global cache associated with said secondary buffering component and 
an end-user node, or where said secondary buffering component is associated with an 
intermediate node, said at least one global cache is either associated with said secondary 
buffering component, or associated with an end-user node and interfaced with said 
secondary buffering component, 
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communications paths for UDP and HTTP messages from the hub node through 
the outbound channel to each secondary buffering component, 

a means controlled by each associated or interfaced secondary buffering component 
of writing files or database records in each associated or interfaced global cache, 

wherein each global cache is accessible by at least one end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange HTTP requests and HTTP responses 
with said hub node using the star network medium or a different telecommunications 
medium. 

13. A caching system for a star topology network, according to claim 9, 10, 1 1, or 12, 
wherein Transmission Control Protocol or a transport layer protocol other than 
Transmission Control Protocol that uses network addressing and routing capabilities of 
Internet Protocol is used, or a protocol other than Hypertext Transport Protocol that uses 
pairednetworklayer addressing and transport layer ports in request/response, cUent/server 
exchanges substantially equivalent to such use in Hypertext Transport Protocol is used, or 
a connectionless protocol other than User Datagram Protocol with broadcast ormulticast 
addressing substantially equivalent to that of User Datagram Protocol is used. 

14. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, and an outbound 
channel, 

at least one end-user node interfaced with a remote terminal in the star topology 
network, and associated wim each such end-user node a secondary monitoring component, 
a decapsulating component, a socket-matching buffering component, and at least one 
global cache, 

a first communications path from the hub node through the primary monitoring 
component, encapsulating component, and outbound channel, thence through the remote 
terminal, the secondary monitoring component and decapsulating componentto each said 

buffering component, 

a second communications path from said one or more external server computers 
through the outbound channel of said hub node, thence through the remote terminal, the 
secondary monitoring component to each said buffering component, 

a means controlled by each said buffering component of writing files or database 
records in said associated global cache, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 
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at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 
15. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, and an outbound 
channel, 

atleastonemtermediatenodemterfac^^ 
network, and associated with each such intermediate node a secondary monitoring 
component, a decapsulating component, and a socket-matching buffering component, 

at least one global cache associated with an end-user node and interfaced with said 

buffering component, 

a first communications path from the hub node through the primary monitoring 
component, encapsulating component, and outbound channel, thence through the remote 
tenninal, the secondary monitoring component and decapsulating component to each said 

buffering component, 

a second communications path from said one or more external server computers 
through the outbound channel of said hub node, thence through the remote terminal, the 
secondary monitoring component to each said buffering component, 

ameans controlledby said buffering component of writing files or database records 

in said interfaced global cache, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 
16. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, and an outbound 
channel, 

atleastonemtermematenodemterfac^wimaremoteterminalm 
network and with at least one end-user node, and associated with each such intermediate 
node isasecondarymomtormg component^ 
buffering component, and at least one global cache, 

a first communications path from the hub node through the primary monitoring 
component, encapsulating component, and outbound channel, thence through the remote 
terminal, the secondary monitoring component and decapsulating component to each said 
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buffering component, 

a second communications path from said one or more external server computers 
through the outbound channel of said hub node, thence through the remote terminal, the 
secondary monitoring component to each said buffering component, 

a means controlled by each said buffering component of writing files or database 
records in said associated global cache, 

wherein each global cache is accessible by at least one end-user node interfaced 
with said intermediate node and contains information or data from said server computers, 
and 

at least one end-user node is able to exchange messages with said hub node usmg 
the star network medium or a different telecommunications medium. 
17. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, a socket-matching 
primary buffering component, and an outbound channel, 

at least one end-user node interfaced with a remote terminal in the star topology 
network, and associated wim each such end-user node a secondary momtoring component, 
adecapsulatmgcomponent,asocket-rnatemngsecondarybuffer^^ 

one global cache, . , 

a first communications path from the hub node through said primary monitoring 
component, encapsulating component, primary buffering component, and outbound 
channel, thence through the remote terminal, said secondary monitoring component and 
decapsulating component to each said secondary buffering component, 

a second communications path from said one or more external server computers 
throughthe primary monitoring component, primary buffering component, and outbound 
channel of saidhub node, thence through the remote terminal, said secondary monitoring 
component to each said secondary buffering component, 

a means controlled by each secondary buffering component of writing files or 
database records in said associated global cache, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node usmg 
5 the star network medium or a different telecommunications medium. 
18 A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
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server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, a socket-matching 

primary buffering component, and an outbound channel, 

atleastonemtermematenodemterfacedwimaremoteterminalmme^ 

network and interfaced with at least one end-user node, and associated with each such 
intermediate node a secondary monitoring component, a decapsulating component, and a 
socket-matching secondary buffering component, 

at least one global cache associated with each said end-user node and interfaced 
with said secondary buffering component, 

a first communications path from the hub node through said primary monitoring 
component, encapsulating component, primary buffering component, and outbound 
channel, thence through the remote terminal, said secondary monitoring component and 
decapsulating component to each said secondary buffering component, 

a second communications path from said one or more external server computers 
through the primary monitoring component, primary buffering component, and outbound 
channel of said hub node, thence through the remote terminal, said secondary monitoring 
component to each said secondary buffering component, 

a means controlled by each secondary buffering component of writing files or 
database records in said interfaced global cache, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 
19. A caching system for a star topology network, comprising: 

a hub node of the star topology network that has access to one or more external 
server computers, and internal to the star topology network has associated with the hub 
node a primary monitoring component, an encapsulating component, a socket-matchmg 

primary buffering component, and an outbound channel, 

atleastonemtermematenodemterfacedwimaremotetermm 

network, and associated with each such intermediate node a secondary monitoring 
component, a decapsulating component, a socket-matching secondary buffering 
component, and at least one global cache, 

a first communications path from the hub node through said primary monitoring 
component, encapsulating component, primary buffering component, and outbound 
, chann el, thence through the remote terminal, said secondary monitoring component and 
decapsulating component to each said secondary buffering component, 

a second communications path from said one or more external server computers 
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through the primary monitoring component, primary buffering component, and outbound 
channel of said hub node, thence through the remote terminal, said secondary monitoring 
component to each said secondary buffering component, 

a means controlled by each said secondary buffering component of writing files or 
database records in said associated global cache, 

wherein each global cache is accessible by at least one end-user node interfaced 
with said intermediate node and contains information or data from said server computers, 
and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 

20. Acachmgsystemforastartopologynetwork,accoro^gtoclaim9, 10, 11, 12, 14, 15, 
16, 17, 18, or 19, wherein the star networking technology is very small aperture satellite 
("VSAT"), multichannel multipoint distribution service ("MMDS"), local multipoint 
distribution service ("LMDS"), instructional television fixed service ('TTFS"), digital 
television broadcasting, or digital cablecasting. 

21 . A caching system for a star topology network, according to claim 9, 10, 1 1, 12, 14, 15, 
16, 17, 18, or 19, wherein a Passive Internet Cache system concurrently uses one or more 
wirelke outbound channels, wireless outbound channels, wireline inbound channels, 
and/or wireless inbound channels. 

22. A caching system for a star topology network, according to claim 14, 15, 16, 17, 18, 
or 19, wherein the network layer protocol is Internet Protocol or a protocol that uses 
networkaddressingandrouting substantially equivalenttothatoflnternetProtocolisused, 
the transport layer protocol used in the first communications path to encapsulate an HTTP 
request is User Datagram Protocol or a connectionless protocol substantially equivalent to 
that of User Datagram Protocol is used, the transport layer protocol used in the second 
communications path is Transport Control Protocol or a connection-oriented protocol 
substantially equivalent to Transport Control Protocol is used, or the applications and 
services protocol is a protocol other than Hypertext Transport Protocol that uses paired 
network layer addressing and transport layer ports in request/response, client/server 
exchanges substantially equivalent to that of Hypertext Transport Protocol. 

23. A caching system for a star topology network, according to claim 14, 15, 16, 17, 18, 
or 19, wherein caching through the second communications path to one or more global 
cache's of specified URLs, or payloads of HTTP messages with specified IP addresses, is 
blocked or authorized by a content authorization program implemented through the first 
communications path. 

24. A caching system for a star topology network, according to claim 14, 15, 16, 17, 18, 
or 1 9, wherein the HTTP responses received through the second communications path are 
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examinedby said buffering component associated with an intennediate node or an end-user 
node, and if said buffering component detects one or more errors in the payload of an 
HTTP response, said buffering component discards each HTTP response containing such 
error(s) and the corresponding buffered HTTP request 

25 A caching system for a star topology network, according to claim 14, 15, 16, 17, 18, 
or 19, wherein there is a means by which HTTP responses received through the second 
communications path are examined by said buffering component associated with an 
intermediate node or an end-user node, and if said buffering component detects an error 
in the payload of an HTTP response and said buffering component is associated with or 
interfaced with an inbound channel, the buffering component extracts the relevant URL 
from the corresponding decapsulated and buffered HTTP request, prepares an HTTP 
request for such URL, and causes the transmission of the prepared HTTP request in such 
inbound channel. 

26. Acachingsystemforastartopology network, according to claiml4,15,or 16,further 
comprising: 

a means by which each HTTP request inbound from a remote terminal is relayed to 
aserver computer andacopy of saidHTTP request is encapsulated in a UDP datagram at 
a hub node and distributed through the first communications path to all secondary 
monitoring components associated with or interfaced with an intermediate node or an end- 
user n ode in the star topology network, each of which secondary monitoring component 
forwards such encapsulated HTTP request to a decapsulating component associated with 
such secondary monitoring component, such decapsulating component decapsulates such 
HTTP request and forwards such decapsulated HTTP request to a buffering component 
associated with such decapsulating component, and such decapsulated HTTP request is 
tagged by the buffering component based on source socket and destination socket and 

buffered; and , 

one or more remote terminals, each of which remote terminals is associated with or 
interfaced with an intermediate node or end-user node and has a means to output each 
HTTP response received through the second communications path to a secondary 
monitoring component associated with or interfaced with such intermediate node or end- 
user node, wherein such secondary monitoring component forwards such HTTP response 
to a buffering component associated with such secondary monitoring component, such 
buffering component examines the source socket and destination socket of such HTTP 
response and the source socket and destination socket of each HTTP request that has been 
buffered and either (a) if the buffering component matches such HTTP response with a 
buffered HTTP request that contains the corresponding source socket and destination 
socket (the source and destination sockets are reversed in the HTTP request as compared 
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with the HTTP response), then the buffering component stores in a global cache associated 
with or interfaced with the buffering component and accessible by one or more end-users 
the contents of the HTTP response under the URL contained in the HTTP request, or (b) 
if the buffering component can not match such HTTP response with a buffered HTTP 
request that contains a corresponding source socket and destination socket, such HTTP 
response is tagged by the buffering component based on source socket and destination 
socket of said HTTP response and buffered, then periodically thereafter the buffering 
component attempts to match the source socket and destination socket of such buffered 
HTTP response with subsequently buffered HTTP requests and upon successfully 
matching the sockets of such HTTP response with the sockets of an HTTP request (the 
source and destination sockets are reversed in the HTTP request as compared with the 
HTTP response), then the buffering component stores in a global cache associated with or 
interfaced with the buffering component and accessible by one or more end-users the 
contents of the HTTP response under the URL extracted from in the HTTP request, and 
ifthesocketsofanHTTP response cannot be matched before the expiration ofan operator- 
defined time, the buffering component discards such HTTP response; if the sockets ofan 
HTTP request cannot be matched before the expiration of an operator-defined time, the 
buffering component discards such HTTP request unless the buffering component has 
access to a forward communications channel and in which case issues an HTTP request 
containing the URL in the unmatched and buffered HTTP request. 
27. A caching system for a star topology network, accordingto claim 17, 18, or 19, further 

comprising: 

a means by which each HTTP request inbound from a remote terminal is relayed to 
a server computer and a copy of such HTTP request is encapsulated in aUDP datagram 
at said hub nodeandbufferedmaprimary buffering component pending the amval at the 
hub node of a corresponding HTTP response, and upon arrival of such corresponding 
HTTP response, said HTTP response is buffered in said primary buffering component and 
said primary buffering component examines the source socket and destination socket of 
such HTTP response and the source socket and destination socket of each HTTP request 
that has been encapsulated and buffered and eimer (a) ffmeprinw buffering component 
matches such buffered HTTP response with an encapsulated and buffered HTTP request 
that contains the corresponding source socket and destination socket (the source and 
destination sockets are reversed in the HTTP request as compared with the HTTP 
response), then the primary buffering component forwards the encapsulated and matched 
i HTTP request through the first communications path to all secondary monitoring 
components associated with or interfaced with an intermediate node or an end-user node 
in the star topology network, each of which secondary monitoring component forwards 
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such encapsulated HTTP request to a decapsulating component associated with such 
secondarymonitormg component 
request andforwardssuchdecapsulate^ 

associated with such decapsulating component, and such decapsulated HTTP request is 
tagged by the secondary buffering component based on source socket and destmaton 
socket and buffered, or (b) if the primary buffering component can not match an 
encapsulated buffered HTTP request with a buffered HTTP- response that contains a 
corresponding source socket and destination socket, the primary buffering component 

either jw«d«HnPi^««^^^ toto ^" nr 

computer and receives a corresponding HTTP response that the secondary buffering 

ojmponentsuccessMy socket-matches, ordlscardssuchen^ 

request, as determined by operator-defmed configuration settings, and only after 

forwardmgofanencapsulatedHTTC^ 

(a)above, the primary buffering component atthehub node forwards the matching HTTP 
response through the second communications channel, and 

a means associated with or interfaced with each intermediate node or end-user node 
that outputs each HTTP response received through the second communications path to a 
secondary monitoring component associated with or interfaced with such intermediate 
node or end-user node, wherein such secondary monitoring component forwards such 
HTTP response to a secondary buffering component associated with such secondary 
monitoring component, such secondary buffering component examines the source socket 
anddestmationsocketofsuchHTTP^^ 

of each HTTP request that has been buffered and either (a) if the secondary buffering 
component matches suchHTTP response with a buffered HTTP request that contains the 
corresponding source socketanddestinationsocket(the source and destination sockets are 
reversed in the HTTP request as compared with the HTTP response), then the secondary 
buffering component stores in a global cache associated with or interfaced with the 
secondary buffering component and accessible by one or more end-users the contents of 
the HTTP response under the URL contained in the HTTP request, or (b) if the secondary 
buffering component can not match such HTTP response with a buffered HTTP request 
that contains a corresponding source socket and destination socket, such HTTP response 
is tagged by the secondary buffering component based on source socket and destination 
socket of said HTTP response and buffered, then periodically thereafter the secondary 
buffering component attempts to match the source socket and destination socket of such 
, buffe redHTTP reS ponsewimsubs 

matching the sockets of such HTTP response with the sockets of an HTTP request (the 
source and destination sockets are reversed in the HTTP request as compared with the 
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HTTP response), then the secondary buffering component stores in a global cache 
associated with or interfaced with the secondary buffering component and accessible by 
one or more end-users the contents of the HTTP response under the URL extracted from 
in the HTTP request, and if the sockets of an HTTP response cannot be matched before the 

5 expiration of an operator-defined time, the secondary buffering component discards such 
HTTP response; if the sockets of anHTTP request cannot be matched before the expiration 
of an operator-defined time, the secondary buffering component discards such HTTP 
requestunlessthesecondary buffering componenthas access to aforward communications 
channel and in which case issues an HTTP request containing the URL in the unmatched 

10 and buffered HTTP request. 

28. A method of encapsulation and passive listening, comprising: 

receiving and buffering on a hub node of a network a message from a first network 
node to said hub node, encapsulating said message within a broadcast or multicast 
message, and transmitting said broadcast or multicast message to one or more other 

15 networknodesunabletoreceivemeorigindmessagetransimssionfr 

node to said hub node, 

receivmgsaidbroadcastormulticastmessage,andunencapsulatmgandbuffermgs 

original message from said first node, when said broadcast or multicast message arrives 

at each of said one or more other network nodes, and 
20 storing the contents of the decapsulated and buffered message in cache memory or 

storage accessible by an end-user at each of said one or more other network nodes. 

29. A method of encapsulation and passive listening, comprising: 

receiving and buffering on a hub node of a network a message from a first network 

node to said hub node, selecting said message for encapsulation based on one or more 
25 criteria, such as being an HTTP request or being addressed to a certain network address or 

socket, encapsulating said message within a broadcast or multicast message, and 

transmitting said broadcast or multicast message to one or more other network nodes 

unable to receive the original message transmission from said first network node to said 

hub node, 

when said broadcast or multicast message arrives at each of said one or more other 
network nodes, receiving said broadcast or multicast message, and unencapsulating and 
buffering said original message from said first node, at each of said one or more other 
network nodes, and 

storing the contents of the decapsulated and buffered message in cache memory or 
storage accessible by an end-user at each of said one or more other network nodes. 
30. Amethod of encapsulation and passive 1^^ 

said message transmitted from said hub node to said one or more other network nodes is 



30 



49 



PCT/US01/15575 

WO 01/88761 

encapsulated in User Datagram Protocol or a transport layer, connectionless protocol 
substantially equivalent to User Datagram Protocol. 
31, A method of socket matching, comprising: 

receiving and buffering on a hub node of a network an HTTP request from a first 
network node to said hub node, forwarding said HTTP request to a server computer and 
also copying said HTTP request and transmitting said HTTP request to one or more other 
network nodes unable to receive the original transmission of said HTTP request from said 
first network node to said hub node, receiving an HTTP response sent by said server 
computer in response to said HTTP request, and transmitting said HTTP response to said 
first network node and to said one or more other network nodes, 

at each of said one or more other network nodes, receiving and buffering said HTTP 
request when it arrives, and receiving and buffering said HTTP response when it arrives, 
in buffer memory associated with or interfaced with each of said one or more other 
network nodes, 

in said buffer memory at each of said one or more other network nodes, matching the 
source socket and destination socket of a buffered HTTP request with the source socket 
and destination socket of a buffered HTTP response (the source and destination sockets are 
reversed in the HTTP request as compared with the HTTP response) sent by the server 
computer in response to said HTTP request and received before or after receipt of said 
HTTP request, and 

storing under the URL specified in the matching HTTP request the contents of the 
matched HTTP response in cache memory accessible to an end-user node, which end user 
node is associated with or interfaced with one of said one or more other network nodes. 
32. A method of socket matching, comprising: 

receiving and buffering on a hub node of a network an HTTP request from a first 
network node to said hub node, forwarding said HTTP request to a server computer and 
also copying said HTTP request and buffering in buffer memory said copied HTTP 
request until such time as an HTTP response sent by said server computer in response to 
said HTTP request is received, buffered, and matched as described below at said hub node 

receiving and buffering at said hub node an HTTP response sent by said server 
computer in response to said HTTP request 

in said buffer memory said hub node, matching the source socket and destination 
socket of a buffered HTTP request with the source socket and destination socket of a 
buffered HTTP response (the source and destination sockets are reversed in the HTTP 
request as compared with the HTTP response) sent by the server computer in response to 
said HTTP request and received before or after receipt of said HTTP request, and 

transmitting said matched HTTP request from said hub node to one or more other 
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network nodes unableto receive the original transmission of said HTTP request ftom said 

firstnetworknodeto saidhub node, ^ 

first network node and to said one or more other network nodes, 

at each of said one or more other network nodes, receiving and buffering said HTTP 
request when it arrives, and receiving and buffering said HTTP response when it arrives, 
in buffer memory associated with or interfaced with each of said one or more other 
network nodes, 

in said buffer memory at each of said one or more other network nodes, matching the 
source socket and destination socket of a buffered HTTP request with the source socket 
and destimuonsocketofabufferedHTTPresponse(the source and destination sockets are 
reversed in the HTTP request as compared with the HTTP response) sent by the server 
computer in response to said HTTP request and received before or after receipt of said 
HTTP request, and 

storing under the URL specified in the matching HTTP request the contents of the 
matched HTTP response in cache memory accessible to an end-user node, which end user 
node is associated with or interfaced with one of said one or more other network nodes. 

33. Amemodofsocketmatchmg,accordingtoclaim31 or 32, wherein Transmission 
Control Protocol or a transport layer protocol other than Transmission Control Protocol 
that uses network addressing and routing capacities of Internet Protocol, or a protocol 
other than Hypertext Transport Protocol that uses paired network layer addressing and 
transport layer ports in request/response, client/server exchanges substantially equivalent 
to that of Hypertext Transport Protocol, is used. 

34. Amemodofsocketmatching,accordingtoclaim31 or 32, wherein the network is a 
star topology network selected ftom the group consisting of very small aperture satellite, 
multichannel multipoint distribution service, local multipoint distribution service, 
instructional television fixed service, digital television broadcasting, and digital 
cablecasting. 

35. Amethodof socket matching, according to claim 31 or 32, wherein each said copy of 
an HTTP request is encapsulated in a broadcast or multicast message before transmission 
ftom said hub node and is decapsulated upon receipt and prior to buffering at each of said 
one of more other network nodes. 

36. A caching method for a star topology network, comprising: 

receiving HTTP requests ftom one or more remote terminals at a hub node of the star 
topology network, interfacing said hub node with at least one external server computer.and 
transmitting UDP datagrams, HTTP requests, and HTTP responses in an outbound channel 
from said hub node of the star topology network, and 
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receiving said UDP datagrams, HTTP requests, and HTTP responses at one or more 
intermediate or end-user nodes associated with or mterfacedwimaremote terminal of said 
star topology network, socket-matching said HTTP requests and HTTP responses at said 
one or more intermediate or end-user nodes, and storing in an end-user accessible cache 
5 associated with or interfaced with said one or more intermediate or end-user nodes the 
contents of a given HTTP response under the URL extracted fiom a correctly matched 
HTTP request 

37. A caching method for a star topology network, comprising: 

receiving HTTP requests fiom one or more remote terminals at a hub node of the star 
10 topology network, interfacing said hub node with at least one external server computer, 
socket-matching HTTP requests and HTTP responses at said hub node, and transmitting 
UDP datagrams, HTTP requests, and HTTP responses in an outbound channel fiom said 
hub node of the star topology network to said one or more remote terminals, and 

receiving said UDP datagrams, HTTP requests, and HTTP responses at one or more 
15 intermediate or end-user nodes associated with or interfaced with a remote terminal of said 
star topology network, socket-matching said HTTP requests and HTTP responses at said 
one or more intermediate or end-user nodes, and storing in an end-user accessible cache 
at said one or more intermediate or end-user nodes the contents of a given HTTP response 
under the URL extracted fiom a correctly matched HTTP request. 
20 38. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating with the hub node 
a primary monitoring component, an encapsulating component, and an outbound channel, 
associating with at least one intermediate node or end-user node interfaced with a 
25 remote terminal in the star topology network a secondary monitoring component, a 
decapsulating component, and a socket-matching buffering component, 

associating with saidbuffering component and an end-user node at least one global 
cache, or where said buffering component is associated with an intermediate node, 
associating with or interfacing with said buffering component and an intermediate node at 

30 least one global cache, 

providing communications paths for UDP and HTTP messages fiom the hub node 
through the outbound channel to each buffering component, 

controlling the writing of files or database records in said global cache by means 
of said associated or interfaced buffering component, 

wherein each global cache is accessible by at least one end-user node and contains 
information or data from said server computers, and 

atleast one end-user node is able to exchange HTTP requests and HTTP responses 
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with said hub node using the star network medium or a different telecommunications 
medium. 

39. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating with the hub node 
aprimarymonitoring component, anencapsmatingcomponent,asocket-matchmgprimary 
buffering component, and an outbound channel, 

associating with at least one intermediate node or end-user node interfaced with a 
remote terminal in the star topology network a secondary monitoring component, a 
decapsulating component, and a socket-matching secondary buffering component, 

associatmgwimsaidsecondarybuffermgcomponentandanend-usernodeatleast 

one global cache, or where said secondary buffering component is associated with an 
intermediate node, associating with or interfacing with said secondary buffering 
component and an intermediate node at least one global cache, 

providing communications paths for UDP and HTTP messages from the hub node 
through the outbound channel to each secondary buffering component, 

controlling the writing of files or database records in said global cache by means 
of said associated or interfaced secondary buffering component, 

wherein each global cache is accessible by at least one end-user node and contains 
information or data from said server computers, and 

atleast one end-usernode is able to exchange HTTP requests andHTTP responses 
with said hub node using the star network medium or a different telecommunications 
medium. 

40. A caching method for a star topology network, according to claim 36, 37, 38, or 39, 
wherein Transmission Control Protocol or a transport layer protocol other lhan 
Transmission Control Protocol that uses the network addressing and routing capabilities 
ofmtemetProtocolisused,oraprotocolo^ 
pafrednetwwklayeraddie^ 

exchanges substantially equivalent to such me in Hypertext Transport Protocol is used, or 
aconnectionless protocol other than User Datagram Protocol with broadcast or multicast 
addressing substantially equivalent to that of User Datagram Protocol, is used. 

41. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
servercomputers,andmternaltomestartopologynetworkassociatm^ 
aprimarymonitoring component, an encapsulating component, and an outbound channel, 

associating with at least one end-usernode interfaced with a remote terminal in the 
star topology network a secondary monitoring component, a decapsulating component, a 
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socket-matching buffering component, and at least one global cache, 

providing a first communications path from the hub node through the primary 
monitoring component, encapsulating component, and outbound channel, thence through 
the remote terminal, the secondary monitoring component and decapsulating component 
to each said buffering component, 

providing a second communications path from said one or more external server 
computers through the outbound channel of said hub node, thence through the remote 
terminal, the secondary monitoring component to each said buffering component, 

controlling the writing of files or database records in said associated global cache 
by means of said buffering component, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 
42. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external server 
computers, and internal to the star topology network associating with the hub node a 
primary monitoring component, an encapsulating component, and an outbound channel, 
associating with at least one intermediate node interfaced with a remote terminal m 
mestartopologynetworkasecona^momtormgcomponent,adecapsmatmgcompo 

and a socket-matching buffering component, 

associating at least one global cache with at least one end-user node interfaced with 

said buffering component, 

providing a first communications path from the hub node through the primary 
monitoring component, encapsulating component, and outbound channel, thence through 
the remote terminal, the secondary monitoring component and decapsulating component 
to each said buffering component, 

providing a second communications path from said one or more external server 
computers through the outbound channel of said hub node, thence through the remote 
terminal, the secondary monitoring component to each said buffering component, 

controlling the writing of files or database records in said interfaced global cache by 

means of said buffering component, 

whereinsaidglobalcacheisaccessiblebysaidend-iisernodeandcontaimmfo^^ 

or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using the 
star network medium or a different telecommunications medium. 
43. A caching method for a star topology network, comprising: 
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interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating with the hub node 
a primary monitoring component, an encapsulating component, and an outbound channel, 

associating with at least one intermediate node interfaced with a remote terminal 
in the star topology network a secondary monitoring component, a decapsulating 
component, a socket-matching buffering component, and at least one global cache, 

providing a first communications path from the hub node through the primary 
monitoring component, encapsulating component, and outbound channel, thence through 
the remote terminal, the secondary monitoring component and decapsulating component 
to each said buffering component, 

providing a second communications path from said one or more external server 
computers through the outbound channel of said hub node, thence through the remote 
terminal, the secondary monitoring component to each said buffering component, 

controlling the writing of files or database records in said associated global cache 
by means of said buffering component, 

wherein each global cache is accessible by at least one end-user node interfaced 
with said intermediate node and contains information or data from said server computers, 
and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 
44. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating with the hub node 
aprimarymonitoring component, an encapsmatmg component, a swket-niatchmg primary 
buffering component, and an outbound channel, 

associating with at least one end-user node interfaced with aremote terminal in the 
star topology network a secondary monitoring component, a decapsulating component, a 
socket-matching secondary buffering component, and at least one global cache, 

providing a first communications path from the hub node through said primary 
monitoring component, encapsulating component, primary buffering component, and 
outbound channel, thence through the remote terminal, said secondary monitoring 
component and decapsulating component to each said secondary buffering component, 

providing a second communications path from said one or more external server 
computers through the primary monitoring component, primary buffering component, and 
outbound channel of said hub node, thence through the remote terminal, said secondary 
monitoring component to each said secondary buffering component, 

controlling the writing of files or database records in said associated global cache 
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by means of said secondary buffering component, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 
45. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating with the hub node 
aprimary monitoring component, an encapsulating component, a socket-matching primary 
buffering component, and an outbound channel, 

associating with at least one intermediate node interfaced with a remote terminal 
in the star topology network a secondary monitoring component, a decapsulating 
component, and a socket-matching secondary buffering component, 

associatmg at least one global cache wto 
said secondary buffering component, 

providing a first communications path from the hub node through said primary 
monitoring component, encapsulating component, primary buffering component, and 
outbound channel, thence mrough toe remote terminal, said secondary monitoring 
component and decapsulating component to each said secondary buffering component, 

providing a second communications path from said one or more external server 
computers through the primary monitoring component, primary buffering component, and 
outbound channel of said hub node, thence through the remote terminal, said secondary 
monitoring component to each said secondary buffering component, 

controlling the writing of files or database records in said interfaced global cache 
by means of said secondary buffering component, 

wherein said global cache is accessible by said end-user node and contains 
information or data from said server computers, and 

at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 
46. A caching method for a star topology network, comprising: 

interfacing a hub node of the star topology network with one or more external 
server computers, and internal to the star topology network associating with the hub node 
aprimary monitoring component, an encapsdatmg component, a socket-matchmg primary 
buffering component, and an outbound channel, 

associating with at least one intermediate node interfaced with a remote terminal 
in the star topology network a secondary monitoring component, a decapsulating 
component, a socket-matching secondary buffering component, and at least one global 
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cache, 

providing a first communications path from the hub node through said primary 
monitoring component, encapsulating component, primary buffering component, and 
outbound channel, mence through the remote terminal, said secondary monitonng 
component and decapsulating component to each said secondary buffering component, 

providing a second communications path from said one or more external server 
computers throughmeprirnarymomtormg component, primary bml^^ 
outbound channel of said hub node, thence through the remote terminal, said secondary 
monitoring component to each said secondary buffering component, 

controlling the writing of files or database records in said associated global cache 
by means of said secondary buffering component, 

wherein each global cache is accessible by at least one end-user node interfaced 
with said intermediate node and contains information or data from said server computers, 

^ at least one end-user node is able to exchange messages with said hub node using 
the star network medium or a different telecommunications medium. 

47 A caching method for a star topology network,' according to claim 36, 37, 38, 40, 41 , 
42 43, 44, 45, or 46, wherein the star networking technology is very small aperture 
satellite ("VSAT"), multichannel multipoint distribution service ("MMDS"), local 
mmtipomt distribution semce 

digital television broadcasting, or digital cablecasting. 

48 A caching method for a star topology network, according to chum 36, 37, 38, 40, 41, 
42 43 44 45 or 46, wherein a Passive Internet Cache system concurrently uses one or 

. mo rewireUneoutboundchamek,wirelessoutboundch^^ 
and/or wireless inbound channels. 

49 A caching method for a star topology network, according to claim 41, 42, 43, 44, 45, 
or 46 wherein the network layer protocol is Internet Protocol or a protocol that uses 

networkadtossmgandroutingsub^^ 

me transport layer protocolusedmmefirstcommumcationsp 

j re.uestisUserDatagramP^ 

that of User Datagram Protocol is used, the transport layer protocol used in the second 
communications path is Transport Control Protocol or a connection-oriented protocol 
substantially equivalent to Transport Control Protocol is used, or the applications and 
services protocol is a protocol other than Hypertext Transport Protocol that uses paired 

5 network layer addressing and transport layer ports in request/response, chent/server 
exchanges substantially eqm^^ 

50. A caching method for a star topology network, according to claim 41, 42, 43, 44, 45, 
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or 46, wherein caching through the second communications path to one or more global 
cache's of specified URLs, or payloads of HTTP messages with specified IP addresses, is 
blocked or authorized by a content authorization program implemented through the first 
communications path. 

51. A caching method for a star topology network, according to claim 41, 42, 43, 44, 45, 
or 46, wherein the HTTP responses received throughthe second communications path are 
examhed by said buffemg component as^ 

node, and if said buffering component detects one or more errors in the payload of an 
HTTP response, said buffering component discards each HTTP response containing such 
error(s) and the corresponding buffered HTTP request. 

52. A caching method for a star topology network, according to claim 41, 42, 43, 44, 45, 
or 46, wherein mere is a means by which HTTP responses received through the second 
communications path are examined by said buffering component associated with an 
intermediate node or an end-user node, and if said buffering component detects an error 
in the payload of an HTTP response and said buffering component is associated with or 
interfaced with an inbound channel, the buffering component extracts the relevant URL 
fiom the corresponding decapsulated and buffered HTTP request, prepares an HTTP 
request for such URL, and causes the transmission of the prepared HTTP request in such 
inbound channel. 

53. A caching method for a star topology network, according to claim 41, 42, or 43, 
farther comprising: 

relaying each HTTP request inbound from a remote terminal through the hub node to 
aserver computer and encapsulating a copy of each said HTTP request in a UDP datagram 
at said hub node, distributing said UDP datagram Ihrough the first communications path 
todlsecondarymomtoringcomponentsassoc^ 

node or an end-user node in the star topology network, forwarding such encapsulated 
HTTP request from each such secondary monitoring component to a decapsulating 
component associated with each such secondary monitoring component, decapsulating 
such HTTP request in the decapsulating component, forwarding such decapsulated HTTP 
requestfromsuchdecapsdatmgcomponenttoabufferingcomponentassociatedwithsuch 

decapsulating component, and tagging by such buffering component of each such 
decapsulated HTTP request based on source socket and destination socket and buffered; 
and 

associating with or interfacing with one or more remote terminals an intermediate 
node or end-user node, outputting from each such remote terminal each HTTP response 
received through the second communications path to a secondary monitoring component 
associated with or interfaced with such intermediate node or end-user node, forwarding 
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from the secondary monitoring component such HTTP response to a buffering component 
associated with such secondary monitoring component, examining the source socket and 
destination socket ofsuchHTTP response and the source socket and destination socket of 
each HTTP request that has been buffered by such buffering component, and either (a) if 
the buffering component matches suchHTTP response with a buffered HTTP request that 
conlainsthecorresp^ 

sockets are reversed in the HTTP request as compared with the HTTP response), then 
stormgbythebuffermgcomponentmaglobalcache associated wimormterfa^ 

secondary buffering component and accessible by one or more end-users the contents of 
the HTTP response under the URL contained in the HTTP request, or (b) if the buffering 
componentc^notnmtchsuchHTTPresponsewimabufferedHTTPrequestt^ 

acorresponding source socket and destination socket, tagging suchHTTP response by the 
buffermgcomponentbasedonsourcesocketandde^auonsocketofsaidHTTPre 

and buffering such tagged HTTP response, then periodically thereafter attempting by the 
buffering component to match the source socket and destination socket of such buffered 
HTTP response with subsequently buffered HTTP requests and upon successfully 
matching the sockets of such HTTP response with the sockets of an HTTP request (the 
source and destination sockets are reversed in the HTTP request as compared with the 
HTTP response), storing by the buffering component in a global cache associated with or 
interfaced with the secondary buffering component and accessible by one or more end- 
users the contents of the HTTP response under the URL extracted from in the HTTP 
request and if the sockets of an HTTP response cannot be matched before the expiration 
of an operator-defined time, discarding by the buffering component of such HTTP 
response; if the sockets of an HTTP request cannot be matched before the expiration of an 
ope ra tor-defmedtime,todmgbymebuffermgconn»onen^ 

the buffering component has access to a forward communications channel and m which 
case issuing by the buffering component of an HTTP request containing the URL m the 
unmatched and buffered HTTP request. 

54. A caching method for a star topology network, according to claim 44, 45, or 46, 

further comprising: 

relaymgeachHTTPrequestmboundfremarmotetermind 

aserver computer and encapsulatmg a copy ofeach said HTTP request in a UDP datagram 

at S aidhubnode,buffermg S aidUDPaatagrammaprimary buffering component pending 

the arrival at the hub node of a corresponding HTTP response, and upon arrival of such 

, corresponding HTTP response, buffering said HTTP response in said primary buffering 

component, examining by said primary buffering component of the source socket and 

delation socketofsuchHTITre^ 
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each HTTP request that has been encapsulated and buffered and either (a) if the primary 
buffering component matches such buffered HTTP response with an encapsulated and 
buffered HTTP request that contains the corresponding source socket and destination 
socket (the source and destination sockets are reversed in the HTTP request as compared 
with the HTTP response), forwarding by the primary buffering component of the 
encapsulated and matched HTTP request through the first communications path to all 
secondary monitoring components associated with or interfaced with an intermediate node 
or an end-user node in the star topology network, forwarding by each such secondary 
monitoring componentsof such encapsulated HTTP request to a decapsulating component 
associated wim such secondary monitoring component, decapsulatingbythedecapsulating 
component of such HTTP request, forwarding such decapsulated HTTP request to a 
secondary buffering component associated with such decapsulating component, and 
tagging of such decapsulated HTTP request by the secondary buffering component based 
on source socket and destination socket and buffered, or (b) if the primary buffering 
component cannot match an encapsulated buffered HTTP request with a buffered HTTP 
response that contains a corresponding source socket and destination socket, either issuing 
by the primary buffering component of another HTTP request, without encapsulation, 
addressed to the relevant server computer and receiving a corresponding HTTP response 
that the secondary buffering component successfully socket-matches, or discarding such 
encapsulated and buffered HTTP request, as determinedby operator-defined configuration 
settings, and only after forwarding of an encapsulated HTTP request through the first 
communications path under (a) above, forwarding by the primary buffering component at 
the hub node of the matching HTTP response through the second communications channel, 
and 

associating with or interfacing with one or more remote terminals an intermediate 
node or end-user node, outputting from each such remote terminal each HTTP response 
received through the second communications path to a secondary monitoring component 
associated with or interfaced with such intermediate node or end-user node, forwarding 
from the secondary monitoring component such HTTP response to a secondary buffering 
component associated with such secondary monitoring component, examining the source 
socket and destination socket ofsuch HTTP response and the source socket and destination 
socket of each HTTP request that has been buffered by such secondary buffering 
component, and either (a) if the secondary buffering component matches such HTTP 
response with abuffered HTTP request that contains the corresponding source socket and 
destination socket (the source and destination sockets are reversed in the HTTP request as 
compared with the HTTP response), then storing by the secondary buffering component 
inaglobal cache associated withor interfaced withthe secondary buffering component and 
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accessible by one or more end-users the contents of the HTTP response under the URL 
contained in the HTTP request, or (b) if the secondary buffering component can not match 
such HTTP response with a buffered HTTP request that contains a corresponding source 
socket and destination socket, tagging such HTTP response by the secondary buffering 
5 component based on source socket and destination socket of said HTTP response and 
buffering such tagged HTTP response, then periodically thereafter attempting by the 
secondary buffering component to match the source socket and destination socket of such 
buffered HTTP response with subsequently buffered HTTP requests and upon successfully 
matching the sockets of such HTTP response with the sockets of an HTTP request (the 
10 source and destination sockets are reversed in the HTTP request as compared with the 
HTTP response), storing by the secondary buffering component in a global cache 
associated with or interfaced with the secondary buffering component and accessible by 
one or more end-users the contents of the HTTP response under the URL extracted from 
in the HTTP request, and if the sockets of anHTTP response cannot be matched before the 
15 expirationofanoperator^efmedtime^ 

of such HTTP response; if the sockets of an HTTP request cannot be matched before the 
expiration of an operator-defined time, discarding by the secondary buffering component 
of such HTTP request unless the secondary buffering component has access to a forward 
communications channel and in which case issuing by the secondary buffering component 
20 of an HTTP request containing the URL in the unmatched and buffered HTTP request. 
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